Чт. Июл 29th, 2021
    DeVex #12, Free TON,

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

    О разработке механизма авторизации

    Ivan Kotelnikov упомянул, что уже существует решение от TON Labs в open source, которое позволяет наделить человека токеном и потом определенным способом проверить и авторизовать по публичному ключу. Но на основе этого решения можно что-то придумать еще.

    Pavel P рассказал также про еще одно универсальное предложение, при котором на клиенте ключ разбивается локально на 3 части. ”Например человеком делается гугл логин и фактически подписывается операция — так выглядит юзер экспириенс (UX). У нас уже есть люди, которые интегрируют такую схему. В общем и целом, это очень неплохой UX. Его можно изменять, улучшать, делать более безопасным, привязывая его к мультисигу, но в целом такого рода историй можно моделировать много”.

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

    Pavel P согласен, что нет проблем сделать схемы авторизаций, но по его мнению, надо просчитывать, что у разных аудиторий свои потребности: “Для кого-то recovery важно, для кого-то security, для кого-то удобство. Чем больше будет разработано схем авторизаций и доступно из коробки, тем больше будет использоваться”.

    Mitja же высказал обратную точку зрения, что не видит особого смысла в проведении этого конкурса, т.к. считает, что авторизацию может сделать каждый сам: “Например, у нас есть начальная схема авторизации, мы потом еще будем развивать. Бери, пользуйся. Есть схема у ребят-партнеров — бери пользуйся. Все равно все делается под юзкейс”.

    Но все же после онлайн-голосования решили, что конкурсу быть.

    Pavel P предложил написать схему более широко, причем может быть три направления фокуса:

    • удобство;
    • восстановление;
    • безопасность.

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

    Также Pavel P предложил провести мини-эксперимент. Если зайти в iPhone во вкладку «Пароли» и нажать рекомендации по безопасности, можно узнать, сколько аккаунтов и паролей скомпрометировано, т.е. их можно купить на рынке. “Это я к тому, — поясняет Pavel P, — что эта система логин-пароль must die (должна умереть) и только авторизация через блокчейн должна работать в будущем. Ну, конечно, если вы не доверяете гуглу, который может что-то отключить, потому что нарушил какую-то политику — непонятно чью и непонятно где”.

    Ivan подвел к общему знаменателю все высказывания: “Нужно добавить список жюри, убрать специфику смарт-контракта и в требованиях попросить указать целевую аудиторию и юзкейс, для которого разрабатывается такой дизайн, добавить recovery и удобство”.

    Система голосования во Free TON: как все-таки быть?

    Free TON Voting

    Животрепещущий вопрос по голосованию продолжает будоражить умы. И это неудивительно, когда столько недочетов и недосказанностей, срочно необходимо приходить к общему знаменателю, чтобы не наступать каждый раз на те же грабли. Anazarov79, например, отметил, что нужно всегда задавать в смарт-контракт список жюри, причем именно тех, кто судит.

    Далее началась дискуссия по поводу распределения призовых мест при условиях 50+1.

    Если 50+1 и reject, будет ли заявка участвовать в дальнейшем рассмотрении? Все же реджект означает, что кто-то из судей посчитал, что условия не выполнены, а значит, по идее, все остальные голоса нивелируются.

    Также в очередной раз затронут вопрос по поводу abstain (воздержание от голосования). Aleksandr Hramcov недоумевает, как быть в таком, например, случае, когда было 4 голосующих, при этом один голосовать отказался, потому что аффилирован с участником, два других реджектнули — и этого недостаточно, чтобы отклонить заявку? Т.е. по сути аффилированный человек все равно должен рассмотреть заявку.

    Например, Mitja уверен, что люди в жюри просто не могут не иметь мнения (это к вопросу по abstain), ведь они изначально должны быть квалифицированными. И изменять смарт-контракты ради этого нет смысла.

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

    Alex Novikov предлагает более жесткие критерии: считать только те заявки, за которые проголосовали больше половины, не учитывая абстейн и реджект. Ivan одобрил идею, но эти изменения будут уместным с большим призовым пулом: “Сейчас у нас конкурсная система не такая гибкая, чтобы вводить ручной подсчет голосов”.

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

    Marina предложила проголосовать и решить, остается ли все так, как прописано в смарт-контракте (если 50+1 реджект среди проголосовавших, то заявка автоматом отклоняется), или нужно поменять на предложение Alexey — если заявка получает 50+1 “ЗА”, тогда она участвует в пуле распределения призов.  По итогу — большинство за первый вариант — оставить все, как есть.

    Rejection условиям быть?

    Boris отметил, что условия конкурса — это же и критерии, которые влияют на оценку. А т.к. условия должны быть удовлетворены все, то их не должно быть много.

    Marina согласилась, что все должно быть четко прописано внутри конкурса и обязательно удовлетворены все пункты условий, а при невыполнении лишь одного — заявка отклоняется. Это хорошее подспорье для судей.

    Pavel P как человек, который часто участвовал в судействе, отметил, что писать критерии — отличная идея: “У нас есть, условно говоря, обязательные и дополнительные. Но дело в том, что даже обязательные критерии сформулированы порой достаточно широко, это сознательно сделано именно для того, чтобы оставить людям поле для творчества. Поэтому можно написать отдельно rejection критерии, которых заявка может быть отклонена. Это сильно бы упростило работу судей”.

    Alex Novikov нашел в этом несовершенство: «Мы используем и русский, и английский язык, но это не формулы, поэтому у текста может быть несколько интерпретаций».

    После голосования постулировали, что в данном конкурсе нужно прописать четкие условия реджекта.

    Естественный отбор в жюри

    Ivan, пользуясь случаем, анонсировал, что будет цепочка конкурсов по смарт-контрактам: «Они нацелены на то, чтобы обучить разработчиков лучшему написанию смарт-контрактов, а также дать им некоторый плацдарм для творчества, чтобы поиграться. Т.е. это будет какой-то написанный кусок кода на основе которого будет предлагаться что-то дополнить, дописать, расширить и т.д. По итогам предлагаю добавлять людей с лучшими решениями в глобальное судейство смарт-контрактов».

    Все проголосовали “ЗА” такие эксперименты.

    3
    0