DApps Haven’t Really Earned That ‘D’ Yet

            Everyone who follows the blockchain industry long enough will agree that drama is, apparently, inherent to cryptocurrencies. In this article we’d like to talk about yet another emotionally rich incident, why we consider it important and what, in our opinion, we should do as a community to prevent such incidents in the future.

          What happened?

            If you followed the development of EOS ecosystem you could notice that blockchain gambling has become a trend. The majority of projects use profit-sharing model, meaning everyone can buy tokens, stake them and receive the share of project’s profit as dividends. Among them was EOSPoker – casino with blackjack and plans to develop the Texas Hold’em. It had quite a big community (that still hopes for the best), lots of users and big volume (thanks to that the project consistently was among top dapps on Dappradar).

            Despite this, things were not so good for the project recently – token’s price went down consistently, dividends became poor and developers’ team was no longer stopping by the community chat. Not so long ago the situation reached its peak – all the casino’s funds has been withdrawn without prior notice:

            Also the unstaking function has been deleted from the EOSPoker’s contract:

            In the end, the projects site was finally disabled. Soon after EOSPoker’s representative left the message, telling that current situation is not an exit scam, but a “failed business”:

            By now, everything is finally relatively calm: users’ tokens that were stuck in a stake were sent back manually, community grieves at the token’s price and discusses how to continue the project’s development without the developers. Particularly the new project has been created (PokerDAC) with new token (which already has been distributed to POKER holders). Also it was decided to develop p2p Texas Hold’em using Graphen Lab’s Decentralized Card Deck Protocol (protocol that allows to create a decentralized infrastructure for card games and unites developers, gamers, games’ operators, and affiliates on the single decentralized platform with common economy).

          Why does it matter?

            All that has happened clearly demonstrates that something is seriously wrong with the principles of decentralized applications’ development.

            To begin with, the majority of existing projects has only part of the logic interacting with EOS blockchain (usually it’s finances-related – payout of winnings, stake and unstake of tokens, distribution of dividends).However the game code is located on a centralized back-end. Such projects don’t really differ from regular online-casinos, meaning developers can “turn off” the app at any time (which, unfortunately, has happened with EOSPoker). This problem can (and should be) solved by implementing the critically important logic in smart-contracts only. But it’s not enough.

            Smart-contracts are mutable in EOS by default (and there’s nothing wrong with it). The problem is you can’t really develop something without mutability – in practice it’s impossible to write perfect, completely bug-free code that predicts all possible scenarios (the brightest example I can recall – there was a critical bug in Bitcoin code, that threatened the network for two years). Furthermore, the new versions of EOSIO (software, on which EOS network operates) are being released constantly, so developers need to update their code accordingly to keep in functional.

            Well, EOSPoker’s community definitely has something to say on this matter:

            Given the context, users above surely do have the point. So, do developers inevitably have to choose between centralization and immutability? Luckily, there is the middle ground that can be a solution.

          What can be done?

            EOSIO has an excellent instrument called Permissions. For the detailed information you can visit this link, but long story short – there is a multi-level system of access permissions that makes your account’s settings flexible, ranging from different keys (active/owner) as a security measure to the complex multi-signature system to set the access permissions for a specific group of people.

             Thanks to Permissions you can implement a system that requires signatures by several keys for some transactions. So how does it allow to reach decentralization with mutable code?

            Probably you’ve heard about Chintai – platform for EOS tokens’ leasing. It has a lot of security measures; in particular 6 of 11 Block Producers (who sponsored the platform) have to sign the transaction to change the contract’s code. This way even if 5 Block Producers will collude to hurt the platform – it won’t be enough. Not to mention that potential profit of an attack is not comparable with the damage to the reputation which will result in voting them out of the top BP list (also none of these teams are anonymous – so they really need to think twice before acting maliciously).

            Someone can consider this solution to be centralized. Well, relatively, maybe it is. But it’s certainly much more decentralized than current system in which developers have unlimited power over the project (theoretically they can delete the entire contract – with all the users’ funds).

            Unfortunately, we haven’t found projects except for Chintai that applied this solution. We at Graphene Lab think that EOS network needs standards for decentralized applications’ development – and are ready to set an example. Our first release of a fully on-chain p2p Texas Hold’em built on the DCD protocol is planned for this month and we take an obligation to do everything we can to prevent the possibility of the situation that happened to EOSPoker.

            First of all, logic and economics of the game will be implemented in smart-contracts only – there won’t be any back-end code that can be secretly “turned off” or changed. After the successful release on the EOS mainnet we will do our best to limit our ability to change the contract’s code – one of the options is to entrust well-known teams with an ideal reputation with some of the keys necessary to do it. Besides that we plan to create the DAO, which will be governed by the community.

            We want to provide unique possibilities to the community: creation of playing networks, poker-rooms with tournaments or private rooms to play with friends. All of it at minimal cost, on a public decentralized infrastructure with in-built economics, flexible settings of commissions, rake-back and referral system, automatic payouts, governing by the community and a lot of more on the top of the open protocol.

            Decentralization for us is not “just a selling word”. And we’d like to believe that other developers share our views. Because either dapps’ ecosystem will change or it won’t be different from existing centralized solutions. And the latter will be really disappointing.

            Best Regards,

            Graphene Lab