Сб. Июл 24th, 2021
    DevEx, Free TON, Meetup

    Обсудили процесс обновления TIP-3, послушали предложение создания консорциума по типу DeBot, поговорили о подписании транзакций — кто же должен этим заниматься и стоит ли устраивать “дежурства”.

    Обновление TIP-3 — статус и текущие проблемы

    На момент встречи стандарт TIP-3 разрабатывался TON Labs в сотрудничестве с Broxus, обсуждалось внесение изменений.

    Есть ограничение на объем используемой памяти (16 КБ), в которую за одно сообщение можно развернуть контракт. Например, для биржевого софта TIP-3 уже не помещается. А ведь помимо этого, также требуется поддержка интерфейсов. TIP-3 должен быть очень компактным. “Надо избрать золотую середину”, — считает Mitja.

    Одно из решений, по мнению Aleksandr Hramcov,— избавиться от опциональных параметров. Также, например, на Solidity отчасти помогло такое изменение — использование паблик модификаторов вместо отдельных гейтеров. “Мы подошли нестандартно, — поделился Aleksandr Hramcov, —  сделали один метод, позволяющий собирать все значения. Как показывает практика, при работе с GraphQL  удобнее использовать один запрос — занимает меньше времени”.

    Но проблема, по мнению Mitja, в том, что не будет полной совместимости TIP-3 токенов, ведь тогда она должна быть совместима по байт-коду: “А это означает, что вы не только на разных языках не напишите, но и по сути разными версиями одного и того же компилятора тоже не сможете”.

    Aleksandr Hramcov предложил обеспечить совместимость токенов TIP-3 на уровне ABI-схемы.

    В случае совместимости байт-кода, поддержки одного токена TIP-3 будет достаточно. “Если, грубо говоря, у тебя есть какая-то биржа, то тебе уже нужно поддержать каждый TIP-3, если они несовместимы по байт-коду, — пояснил Mitja. — А если бы были совместимы, тебе не нужно было бы поддерживать каждый, было бы достаточно одного байт-кода. Плюс это раздувает контракт”.

    Кроме того, считает Mitja, проблемы в случае интерфейса и биржи решаются не с помощью ABI, поэтому несовместимость не настолько важна. С чем Aleksandr Hramcov  не согласен, ведь тогда у дебота должен быть совместимый интерфейс.

    Mitja объяснил свою позицию: “Мы не можем сделать байт-код совместимый с тип-3, поэтому насколько нам нужно закреплять этот интерфейс — это большой вопрос… Зачем нужна ABI совместимость? Деботы и сделаны для того, чтобы унифицировать интерфейс смарт-контракта. Просто пишешь своего дебота под контракт, с которым хочешь делать интерфейс, даешь ему адрес в сети и дальше вывешиваешь на своем сайте. И пишешь в любом кошельке, который поддерживает деботов в браузере, это название — и все”.

    Сейчас Mitja работает над стандартизацией адреса DeBot от смарт-контракта. То есть, зная адрес смарт-контракта, можно всегда найти своего дебота. По умолчанию будет 2 варианта:

    1. DeBot, привязанный к хешу кода. Он будет обслуживать все контракты с этим хеш-кодом.
    2. Вычисление DeBot конкретного смарт-контракта (конкретная копия адреса). Интерфейс TIP-3 опциональный, что означает — у него нет требуемых методов.

    Консорциум по типу DeBot

    Mitja предложил создать консорциум по типу DeBot для токенов, где будет список интерфейсов (1-3 — обязательные). Если бирже нужно поддержать как можно большее количество токенов, ей будет нужно прийти в этот консорциум и поддержать их в нем.

    Совместимость будет поддерживаться на уровне механизма токенов и иметь единый интерфейс. То есть для интерфейсов будет создано одно место. Единственное требование — не повторять интерфейс, чтобы не было много смарт-контрактов с большим количеством интерфейсов.

    Если хочешь сделать какой-то интерфейс, просто вносишь его в консорциум и говоришь: вот новый токен, вот его код, а вот его интерфейс. Mitja

    Идея создания консорциума была принята без возражений.

    Подписание транзакций

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

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

    Alex Novikov заметил, что anazarov79 выполняет множество рутинных задач в DevEx subgovernance, включая подписи, регенерации транзакции, что требует много времени и внимания. И предложил распределить эти обязанности между несколькими людьми — составить график всех, кто входит в initial members или тех, кто желает, и составить дежурство: “Так мы, во-первых, снизим нагрузку на Anazarov79 и, во вторых, получим возможность передавать “тайные знания”. И если что-то случается, у нас есть определенная структура и все продолжает работать”.

    Есть инструкция, созданная anazarov79, где указано, как выполнять основные обязанности initial members. И ее автор предложил более правильный выход, по его мнению — сначала узнать, кто хочет заниматься этой деятельностью, нужно 3-4 человека, и по очереди передавать эти обязанности. Ведь не каждый возьмется за столь ответственное дело, т.к. здесь же завязана бухгалтерия, и любая ошибка может быть чревата последствиями, поэтому заставлять вступать в “дежурство” всех до одного — по меньшей мере нецелесообразно.

    Напоследок…

    Anazarov79 предложил членам DevEx subgovernance следующее: если есть проблема, требующая обсуждения на еженедельной встрече, сразу же включать ее в повестку дня без какого-либо дополнительного напоминания об этом. И лучше заблаговременно.

    3
    0