Встреча DevEx Governance №33 от 10.06.2021

Встреча DevEx Governance №33 от 10.06.2021

Участники meet up обсудили, нужно ли сохранять ABI внутри каждого смарт-контракта и каким образом лучше это делать, поговорили о том, как систематизировать все документы для разработчиков. Также посовещались о необходимости создания SDK для низкоуровневого общения с Rust-нодой и понятных инструментов для сторонних программистов.

Миссия: сохранить ABI

Сергей Тюрин напомнил о ранее выдвинутом им предложении: для общего удобства сделать обязательной такую процедуру — хранить ABI каждого смарт-контракта в самом смарт-контракте. “Очень наглядно была показана такая необходимость при замене контракта электора в Rust Cup, когда забыли выложить обновленную ABI”, — отметил Сергей.

Как вариант, можно просто включить этот пункт в стандарт по смарт-контрактам. По мнению Сергея, если в SDK и TON OS будет поддерживаться такое действие, то на это перейдут и все остальные разработчики, потому что это весьма удобно, ведь не будет необходимости искать ABI офчейн.

Для удобного хранения ABI нужно выбрать понятный алгоритм упаковки.  Сергей Тюрин предлагает всем ZIP PPA. Распаковка будет проходить офчейн.

Решили оповестить об этом Екатерину Пантаз, чтобы она помогла воплотить эту идею в жизнь, а также Бориса Ивановского — нужно, чтобы и его TVM-линкер и другие инструменты поддерживали ABI — извлечение, распаковку и т.д.

Систематизация документации

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

Сергей Тюрин отметил, что Free TON Academy Subgovernance хочет запустить создание курсов, но без нормальной документации по самому блокчейну и ко всем инструментам (SDK, стандартам смарт-контрактов, TIP-2, TIP-3, деботам) писать какие-то курсы проблематично.

Сергей уверен: “Те, кто обучается, должны иметь возможность открыть какой-то ресурс и прочитать, что, например, в client contract есть такие-то методы, у каждого метода вот такие входные и выходные параметры и такие он может сделать ошибки. Причем документацию нужно делать на 2-4 языках”.

А пока у всего того, что есть по всем направлениям, абсолютно нет системности, и очень важно собрать все в одном месте, четко структурировать. Предложение — либо провести конкурс, либо поручить это Academy SG.

По предложению Сергея Тюрина, контест можно назвать: “Выбор формата предоставления документации”, при этом движок Wiki не подходит — в нем нет необходимой древовидной структуры. Главное условие: чтобы абсолютно каждый человек (условно говоря, даже тот, кто уже давно не занимался разработкой, либо представитель из другого блокчейна) мог прийти и сразу понять, где что лежит.

Nerzh согласился в ближайшем будущем предоставить для обсуждения список подходящих движков (наглядно, со скриншотами) и того, что можно сделать.

SDK для низкоуровневого общения с нодой

Иван Котельников рассказал, что поступил запрос от разработчика  о том, что в SDK нужно сделать поддержку прямого взаимодействия с нодами на протоколах низкого уровня.

Сергей Тюрин посчитал хорошей идеей, чтобы SDK был предназначен не только для общения с GraphQL. “Беда еще в чем — у нас реально по низкоуровневому обращению с блокчейном, кроме white paper Дурова, никакой документации нет”, — отметил Сергей.

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

В свою очередь, Сергей предложил сделать другой подход: не через вызовы консоли растовой ноды, а непосредственно обращение в базу, как это делает GraphQL DApp-сервер.

Обертка над обертками: must have

Nerzh рассказал, что один разработчик начал пользоваться его Ruby оберткой, но не знал, как сгенерировать ключи. “Метода нет — это же SDK, обертка, — пояснил Nerzh. — По сути, я за него писал код для приложения”.

У сторонних разработчиков, которые хотят быстро сделать какой-нибудь сайт, по мнению Nerzh, всегда один посыл — создание кошелька, получение/отправка токенов, что-то получить, задеплоить контракт. Им хочется все каким-то образом упростить.

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

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

Узнайте больше про Everscale
Подпишитесь на наши социальные сети и будьте в курсе актуальных новостей
SUBSCRIBE ON SOCIAL
Free TON House
Первоисточник