Обсудили процесс обновления 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 варианта:
- DeBot, привязанный к хешу кода. Он будет обслуживать все контракты с этим хеш-кодом.
- Вычисление 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 следующее: если есть проблема, требующая обсуждения на еженедельной встрече, сразу же включать ее в повестку дня без какого-либо дополнительного напоминания об этом. И лучше заблаговременно.