EOSPoker – Кто Виноват? Что Делать?

            Любому, кто следит за блокчейн-индустрией достаточно долго становится очевидно, что «криптовалюты» и «драма» понятия неразделимые. В этой статье мы бы хотели рассказать об очередном эмоционально насыщенном событии, почему мы считаем его крайне показательным и что в связи с этим необходимо предпринять.

        Что произошло?

            Если вы наблюдали за развитием экосистемы EOS, то могли заметить, что в сети случился бум азартных игр на блокчейне. Большая часть проектов использует модель profit-sharing: можно купить токены проекта, поместить их в стейк и получать часть дохода проекта в виде дивидендов. Одним из таких проектов был EOSPoker – казино с блэкджеком и планами разработать Техасский холдем. Проект явно нельзя было назвать «однодневкой» - у него довольно крупное сообщество, которое до последнего верило (и верит до сих пор) в лучшее, а благодаря объемам и количеству пользователей он уверенно занимал одну из первых строчек на Dappradar.

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

            Таже в коде контракта отключили возможность анстейка токенов (причина последнего до сих пор не ясна):

            Впоследствии был отключен и сайт проекта в целом, а его представитель оставил сообщение, что происходящее – не exit scam, а «неудавшееся предприятие»:

            На данный момент ситуация относительно нормализовалась: застрявшие в стейке средства были вручную возвращены пользователям, сообщество сокрушается над ценой токена и обсуждает, как продолжать развитие проекта без разработчиков. В частности, был создан новый проект (PokerDAC), токены которого были распределены держателям POKER. Для разработки Texas Hold’em было решено использовать разработанный нами Decentralized Card Deck Protocol (протокол для создания и развития децентрализованной инфраструктуры для карточных игр, позволяющий объединить разработчиков, операторов игр, игроков и дочерние проекты на одной децентрализованной платформе с общей экономикой).

        Почему всё это важно?

            Всё произошедшее ненавязчиво намекает, что сообщество разработчиков должно серьезно пересмотреть принципы разработки децентрализованных приложений.

            Начнем с того, что сейчас у большинства проектов только часть кода реализована ончейн (обычно это касается финансов – выплата выигрышей, стейк и анстейк токенов, распределение дивидендов). Основная игровая логика же реализована на бэкенде, который является централизованным сервисом. Подобные проекты мало чем отличаются от обычных онлайн-казино, а значит разработчики могут в любой момент лишить пользователей функционала приложения (что, собственно, и произошло с EOSPoker). Эту проблему можно (и нужно) решить, реализовывая критически важную логику приложения исключительно в смарт-контрактах. Однако, этого все еще недостаточно.

            Дело в том, что контракты в сети EOS можно сделать изменяемыми – и в этом нет ничего плохого. Более того, без этого невозможно обойтись – на практике невозможно написать идеальный код, который предусматривает абсолютно все ситуации и полностью лишен багов (самый яркий пример на моей памяти: сети биткоина 2 года угрожала критическая уязвимость, воспользовавшись которой можно было нарушить работу 90% нод, потратив при этом всего 12,5 BTC). К тому же, постоянно выходят обновления EOSIO – ПО, лежащего в основе всей сети, что также не позволяет коду приложения оставаться неизменным.

            Безусловно, участникам сообщества EOSPoker есть что сказать на этот счет:

            «Если вы не хотите врать самому себе, то стоит признать, что все казино на EOS централизованы, так как разработчики могут менять код на ходу».

            «Чтобы избегать подобных ситуаций, контракты децентрализованных приложений должны быть неизменяемыми».

            «Маякните, когда появится неизменяемое приложение, в которое можно вложиться».

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

        Что можно предпринять?

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

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

            Вероятно, вы слышали про сервис Chintai – платформу для аренды токенов EOS. Помимо прочих мер безопасности, чтобы изменить её контракт необходимы подписи 6 из 11 блок продюсеров, которые спонсировали разработку платформы. Таким образом, даже если 5 блок продюсеров сговорятся и решат навредить платформе (которая создавалась при их же поддержке), этого будет недостаточно. Не считая того, что сама возможность этой ситуации крайне маловероятна – выгода от возможного успеха сговора не покроет репутационный урон и потерянное место производителя блоков (не считая проблем с законом – ни одна из команд блок продюсеров не анонимна).

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

            К сожалению, помимо Chintai, подобных примеров больше не нашлось. Мы, команда Graphene Lab, считаем, что сети EOS необходимы стандарты разработки децентрализованных приложений – и готовы демонстрировать это на собственном примере. Первый полноценный релиз полностью ончейн p2p Техасского Холдема на базе протокола DCD запланирован уже на этот месяц и мы обязуемся сделать все, что от нас зависит, чтобы исключить саму возможность ситуации, которая произошла на днях с проектом EOSPoker.

            Прежде всего, вся логика и экономика игры будет реализована в смарт-контрактах – никакого back-end кода, который можно отключить или тайно изменить. После того, как проект будет успешно запущен в основной сети, мы приложим все усилия чтобы ограничить нашу возможность менять код контрактов – как один из вариантов, мы будем искать команды с хорошей репутацией, которым можно доверить один из наборов ключей, необходимых для изменения кода. Помимо этого, мы планируем реализовать полноценную Децентрализованную Автономную Организацию (DAO), управление которой будет принадлежать сообществу.

            Мы хотим предоставить сообществу уникальные возможности: создание собственной игровой сети, покеррума с возможностью проведения турниров или приватной комнаты для игры с друзьями. Все это – с минимальными затратами, на публичной децентрализованной инфраструктуре со встроенной экономикой, гибкой настройкой всех комиссий, рейкбэка и реферальных отчислений, автоматическими выплатами, голосованием сообщества по ряду ключевых моментов и многое другое на базе открытого протокола.

            Децентрализация для нас – не просто слово. И мы бы хотели верить, что другие команды разработчиков также разделяют наши убеждения. Потому что если экосистема приложений на EOS не начнет меняться, то она мало чем будет отличаться от существующих централизованных решений. А это грустно.

            С уважением,

            Команда Graphene Lab