Уважаемые пользователи Голос!
Сайт доступен в режиме «чтение» до сентября 2020 года. Операции с токенами Golos, Cyber можно проводить, используя альтернативные клиенты или через эксплорер Cyberway. Подробности здесь: https://golos.io/@goloscore/operacii-s-tokenami-golos-cyber-1594822432061
С уважением, команда “Голос”
GOLOS
RU
EN
UA
vox-populi
6 лет назад

Интервью с разработчиками Golos.core и Golos.io - ЧАСТЬ 1

В преддверии приближающегося хардфорка на платформе развернулись бурные дебаты между сторонниками и противниками ХФ. Чтобы положить начало конструктивному диалогу, мы решили пообщаться с разработчиками golos.core и golos.io, обсудив актуальные вопросы о настоящем и будущем ГОЛОСа.
Беседа получилась долгой, но содержательной.

Представляем вашему вниманию первую часть этой интересной дискуссии. Сегодня у нас в гостях Михаил (@nemo1369) и Александр (@kotbegemot) — разработчики блокчейна ГОЛОСа (@goloscore).

О квадратичной и линейной функциях

@phoenix: Миша, первый вопрос. Он волнует очень многих на платформе сегодня и живо обсуждается. Много разговоров идёт про сравнение квадратичной и линейной функции выплат. Много копий сломано. Хотелось бы услышать от специалиста, какой взгляд у тебя на эту проблему? И почему в нынешнем виде хардфорка предпочтительнее сохранить всё-таки квадратичную функцию?

@nemo1369: На самом деле это палка о двух концах. Мы понимаем, что квадратичная функция может быть не всегда хороша. Это важно и декларировалось с самого начала запуска платформы и разговоров об этом было много.

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

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

@kotbegemot: Можно, я добавлю свои 50 копеек? Есть 120-я задача на github (прим. ред. *GitHub - крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки) – внедрение голосуемых параметров, но я не вижу возможности выполнить ее сейчас, потому что если мы возьмемся за делание этой задачи сейчас, то оттянем сроки выполнения много чего (всего текущего хардфорка, по большому счету) ещё дальше. С точки зрения сообщества хардфорк оттягивать навряд ли целесообразно, потому что итоговый результат - обновление блокчейна - будет достигнут не в нужный момент.

О делегировании Силы Голоса

@natasha: А то, что сейчас в этом хардфорке будет делегированная СГ... Я слышала такое мнение, что делегированная СГ идёт в связке с линейной функцией. Что нет смысла в делегированной СГ, если будет квадратичная функция.

@nemo1369: Да, в сообществе бытует такое мнение. Но на самом деле нужно понимать, что с самого начала процесс развития был итеративный. Делегирование и смягчение вполне могут существовать друг без друга. Сообщество опирается на опыт Стимита, на опыт того, что получилось.

@natasha: А что получилось на Стимите? Я не очень хорошо знакома с платформой Стимит, и мне интересно понять мнение специалистов: насколько введение делегированной СГ с линейной функцией улучшило или ухудшило положение пользователей? Каким образом изменилась ситуация?

@nemo1369: Здесь нужно понимать, что с самого начала делегирование было введено без линейной функции. В репозитории можно посмотреть и понять, что были попытки введения этого (делегирование СГ+линейная функция) одновременно. Но потом, я уже не знаю под чьим давлением и почему, это было убрано, выпилено и заменено обратно на квадратичную функцию. И только в следующей версии была внедрена линейная функция распределения.

Стало ли от этого лучше? Об этом лучше судить сообществу. Обычно всегда кому-то становится хуже, кому-то лучше. Я не берусь решать.

@phoenix: Интересно, что мало кто говорит сейчас о том, что при внедрении линейной функции в теории нас ожидает нашествие ботов.

@kotbegemot: Ботов можно клепать сколько угодно. На самом деле есть как паразитные боты, так и позитивные боты. Другое дело, что люди пытаются заработать, не вкладывая ничего. То есть они пытаются просто извлечь деньги, при этом не создавая добавленную ценность, не принося никакой пользы площадке. И это неправильно, это называется умным экономическим термином, забыл как…

@phoenix: По-русски это называется паразитированием.

@kotbegemot: Да, но есть красивый экономический термин… из горного дела, когда руда в горе истощается, и сама гора начинается рушится под собственным весом.

О работе над хардфорком

@natasha: Понятно. Тогда ещё такой вопрос. По поводу того, что подготовка этого хардфорка так затянулась, Миша говорил, что приходилось переписывать каждую строчку. Почему это было необходимо делать? Что там в коде было не так, почему пришлось всё переписывать?

@nemo1369: Здесь в чём дело: надо понимать, что он затянулся не из-за того, что мы тут просто сидим и надолго погрузились в рефакторинг бесконечный, двухгодовой, как это иногда бывает. Нет, ни в коем случае, никто из нас не пытается удовлетворить своё чувство прекрасного.

Вы не забывайте, что мы уже дважды или трижды представляли версию текущего хардфорка для принятия комьюнити. Сначала это было весной. Мы представили её с голосуемыми параметрами. Сообщество сказало: “Подождите, голосуемые параметры рано, давайте чуть позже”. Хорошо, мы побежали их убирать.

Потом мы представили версию ближе к концу лета, где была такая особенность как длина имени асета и бесплатное их создание. Сообщество снова сказало: “Нет, так не пойдёт”. И мы пошли переделывать снова.

То есть текущая версия - это уже третья попытка. Поэтому тут вопрос - принимать ли хоть какую-то версию?

@kotbegemot: Когда пришёл я, у меня с самого начала не было четкой позиции, как у нового человека. После некоторого времени я понял одну вещь: методы достижения консенсуса будут работать, только если заставлять людей совещаться. Иначе как в истории с буридановым ослом, который остался голодным, так как не мог выбрать один из двух стогов сена.

@natasha: А заказ от комьюнити каким образом вы собирается? Люди должны ходить и оставлять что-то на гитхабе? Я, например, как простой пользователь, даже слова такого не знала год назад.

@nemo1369: Ребята, очень вас прошу, не надо использовать термин “заказ от сообщества”. Тут нужно понимать, что вся концепция децентрализованных сетей — это концепция, согласно которой есть команда, которая приходит и представляет своё решение. И так как сейчас такая команда одна, то, конечно же, у нас нет выбора - мы однозначно должны прислушиваться к сообществу.

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

@natasha: То есть сейчас такой взаимодополняемости нет?

@kotbegemot: Не очень понятен термин “взаимодополняемость”.

@natasha: Есть только одна команда разработчиков. Может быть, я использую не совсем верные слова, но я хочу понять, какова идеальная модель, чтобы состоялся диалог и работа двинулась?

@phoenix: Наташа, идеальная модель — это когда есть альтернативная команда разработчиков ядра, которая работает с этой командой.

@natasha: Это команда добровольцев, которая собралась из делегатов и работает параллельно?

@phoenix: Как вариант. Вопрос в том, что для конструктивного диалога, необходимо не только вести его корректно, без переходов на личности и оскорбления, но ещё и на одном профессиональном уровне примерно.

@natasha: Понятно, что если мы с тобой придём в делегаты, мы ничего привнести в развитие блокчейна не сможем. Мы не программисты. Мы не можем оценить сделанного…

@phoenix: Не факт. Мы не будем обсуждать это в рамках данной дискуссии. Но моё мнение таково, что делегат может приносить пользу платформе, не являясь разработчиком. Есть другие виды активности, которые вполне себе могут двигать платформу при условии наличия консенсуса в сообществе. При условии, что согласован ряд задач, который нужно реализовать, и каждый занимается своим делом. Но это возможно только тогда, когда есть договорённость на начальном уровне относительно кода и относительно дальнейшего видения.

@kotbegemot: Ты говоришь ровно те мысли, которые я пытаюсь объяснить. Спасибо большое. У меня точно такая же позиция. У меня есть надежда, что нас ещё когда-нибудь кто-нибудь поддержит. Но пока приходится работать ночью, днём, утром, вечером… Больно, тяжело, но мы работаем, стараемся.

@natasha: Мой вопрос заключался в том, что нужно сделать, чтобы этого достичь? Ну, то есть нужно ли, чтобы появилась вторая команда, либо…

@kotbegemot: Сейчас, видимо, будет очень длинный разговор о том, как работает Эфириум. С моей точки зрения, у Эфириума очень классный подход к разработке. У них есть много команд, которые занимаются разными направлениями внутри одного блокчейна. То есть у них есть команда, которая думает чётко только про сеть. Сутками сидит и думает: надо оптимизировать вот эту часть, как это сделать и все такое. А есть люди, делающие разные штуки, которыми команда сети не хочет заниматься. А есть команда хранилища — она сидит и занимается им. А помимо этого, или лучше - в дополнение к этому работают добровольцы, сторонние программисты, которые улучшают код или добавляют то, что сами наработали. Для меня команда — это несколько человек, которые решили что-то улучшить и пришли с большим патчем.


Продолжение беседы - в нашей следующей публикации…

1
908.779 GOLOS
На Golos с July 2017
Комментарии (14)
Сортировать по:
Сначала старые