Joy令牌 - 在区块链上玩游戏

摘要

Joy游戏技术提供一种新颖的解决方案以连接小型开发人员、软件公司、大型赌场和玩家。它创造了一个游戏生态系统,既赋予玩家权力,又帮助开发人员和赌场降低风险。

缺乏信任和透明度是在线博彩业关注的一个问题。即使较小的网站提供更多“有趣的游 戏”,玩家还是倾向于使用信誉良好的赌场而不是较小的网站,因为玩家自然会被他们所信任的赌场品牌吸引去。Joy游戏技术是一个透明的基于区块链的系统,这将有助于提高对游戏行业的信任度。Joy游戏技术能够使用户在透明和受代码管理的环境中进行游戏。这使得玩家和开发人员对游戏的公平性抱有信心。通过创新的RNG发生器,玩家可以放心,他们玩的游戏既公平又安全。开发人员、赌场和企业从一个提供流动性分享和公平补偿的生态系统中受益。通过连接开发人员和赌场,我们的目标是为了一个最佳的解决方案,Joy游戏的所有参与者都从其中受益。

介绍

现有的游戏市场

现有的游戏生态系统在很大程度上是由声誉驱动的 - 这种声誉是通过增加广告而建立起来的。为了获得和留住玩家,赌场被迫花费大量的钱,通过品牌知名度建立信任和声誉。另外,大型赌场控制游戏的开发。玩家被迫相信这些赌场,因为缺乏透明度意味着玩家不能跟踪他们的赌注,因此不能评估每次赌注的合法性。

较小的开发人员也受到影响,因为他们在发行新游戏时得到很小比例的收入,面临困难,比如缺乏即时的收入和难以进入大型游戏平台。

Joy 游戏解决方案

Joy游戏解决方案基于区块链,它允许开发人员创建这样的游戏:通过智能合约在其后端运行,而不是直接在区块链上运行。由于所有的结果都记录在区块链中,所以欺诈显著降低。因此,玩家可以验证开发人员是否按照区块链上的描述精确地来运行游戏。此外,游戏开发人员和软件公司可以与流动性提供者(例如赌场)进行连接和整合,以提供直接访问他们游戏的接入。赌场和开发人员都从额外的收入和更多的游戏创新中受益。任何特定网站的声誉缺乏可以通过这样的事实来抵消:游戏规则和底层的基础框架都被记录在区块链中(除了游戏在Joy游戏网络上线之前的批准系统之外)。

技术

智能合约

Joy游戏网络依靠分散式的智能合约来保证和记录区块链上的所有内容。通过区块链,我们将能够审核Joy游戏上发生的一切。玩游戏的用户将能够实时查看网络的结果和回报。与传统的赌场不同(定金存到赌场账户内),用户将总是控制他们的Joy令牌钱包(取款更简单,执行更快)。

我们的平台将使用以太坊网络作为基于区块链的生态系统。以太坊网络已经完全建立,被社区所接受和使用,具有全面的图灵语言能力。虽然存在一些延迟问题,但是下面提出了一种中间地带的分散式解决方案,可以显著减少这种延迟。

自主主体(即智能合同)的使用建立系统中的信任,因为赌客和平台之间的任何利益冲突是以分散式的方式进行管理和审计的。由于所有的交易都是通过智能合约完成的,因此不需要第三方的参与,这就保证了每个人都可以随时访问,验证游戏的公平性。

Joy 游戏堆栈

我们的技术堆栈基本上由三个主要部件组成:区块链层、游戏应用程序(后端/前端)和随机数生成器(RNG)。游戏的后端/前端将在数据库上运行,但所有可能导致玩家与平台之间的任何形式争议的部分将通过智能合约在区块链上被分散和审计。

上图演示了经批准的游戏应用程序和Joy技术随机数发生器之间的通信。

区块链层

区块链层有三个功能:令牌管理、游戏结果管理和提供随机数生成器的可审计性。

令牌管理

在传统的在线赌场中,客户为了玩游戏而把钱汇到赌场。这为潜在的欺诈创造了机会。Joy游戏通过使用区块链技术解决了这个问题。所有玩家的资金将存储在每个玩家的Joy令牌钱包中。当玩家下注时,钱将被发送到智能合约,智能合约将以分散的方式管理下注的结果。使用区块链意味着赌场(即Joy游戏平台)在任何时候都不能控制玩家的钱。

总结:

游戏结果管理

对于每个玩家的投注,将使用智能合约。智能合同将管理由系统的所有部分提供的信息(游戏代码、RNG、玩家的输入)。然后,智能合约将验证游戏的结果,并根据既定的合约规则自动将资金分配给合适的人。

例如,玩家A在轮盘赌上开始下注。

  1. 资金将自动发送到轮盘赌合约
  2. 这一轮盘轮回生成的随机数字将被复制并记录在一个智能合约中(注意:所有发生在游戏中的关键内容(RNG和游戏历史记录)都会被记录在智能合约中)。
  3. 利用生成的随机数,游戏代码将结果发送给智能合约
  4. 获胜者将被自动记入信用。如果玩家输了,那么钱将在开发人员和平台管理之间分摊。这个分摊是在开发阶段协商而定,并在玩家输时自动启用。
  5. 最后,玩家可以决定重新开始游戏过程,继续游戏或结束游戏时段。

最初在网络上注册游戏的演示代码

下面的代码演示了在Joy游戏网络上一个游戏注册。注册完全通过以太坊网络完成,因此参与者可以轻松地验证合约是否已经正式被网络批准。通过这个演示,我们看到可以通过GameRegistry()功能调用注册,由此游戏将在Joy游戏网络上注册。(注意:通过setPlatformShare(uint256 newShare)还可以指定要记入开发人员的信用金额。)

    contract GameRegistry is Ownable {
        using SafeMath for uint256;
        address public tokenAddress;
        address[] public gameList;
        uint256 public decimals = 5;
        uint256 public platformShare = 5 * 10**(decimals.sub(2));
        address public controller;
        mapping(address => bool) public gameRegistered;
        event ControllerTransfer(address originalController, address currentController);
        event PlatformShareUpdate(uint256 originalShare, uint256 newShare);
        event GameRegistered(address game);
        event GameDelisted(address game);


        function GameRegistry(address _tokenAddress) {
            owner = msg.sender;
            controller = owner;
            tokenAddress = _tokenAddress;
        }

        function setController(address newController) public onlyOwner {
            require(newController != address(0) && newController != controller);
            ControllerTransfer(controller, newController);
            controller = newController;
        }

        function setPlatformShare(uint256 newShare) public onlyOwner {
            require(newShare < 10**decimals);
            PlatformShareUpdate(platformShare, newShare);
            platformShare = newShare;
        }

        function createGame(string _name, uint256 _payoutRate) public {
            address newGame = new Game(_name, msg.sender, this, tokenAddress, payoutRate);
            require(!gameRegistered[newGame]);
            gameList.push(newGame);
            gameRegistered[newGame] = true;
            GameRegistered(newGame);
        }

        function delistGame(address game) public onlyOwner {
            require(gameRegistered[game]);
            gameRegistered[game] = false;
            GameDelisted(game);
        }

        function registerGame(address game) public onlyOwner {
            Game g = Game(game);
            require(!gameRegistered[game]);
            gameRegistered[game] = true;
            gameList.push(game);
            GameRegistered(game);
        }

        function getGameRegistered(address game) public constant returns (bool registered) {
            return gameRegistered[game];
        }
    }
    

随机数发生器(RNG)的可审计性

游戏行业的一个关键部分是RNG 的可验证性。在传统意义上,RNG 发生器通常由托管游戏的公司进行管理。然而,在我们的例子中,它将被分散化,确然公平,因为每场游戏都将在一个定制的算法上运行,而这种算法依赖于链接到以太坊网络智能合约的RNG 发生器。这在“ 包裹阶段和支付流程” 一节中有更详细的描述。

游戏应用程序(后端和前端管理)

游戏应用程序代码将被托管在我们的伺服器上或通过IPFS/Sia/Storj 网络托管。游戏结果将被传达给智能合约。此后,游戏伺服器将通过IPC 使用JSON RPC将游戏状态提供给区块链。用户体验不会受到区块链的使用/ 可用性的影响,因为所有游戏结果都将立即可用。此项功能可确保用户体验接近传统的游戏性,同时确保过程也完全透明和分散化。连同所产生的具有全面审计性的随机数,每个游戏代码都可以在区块链上访问。

基于区块链信息的随机性

关键是找到一种分散式的RNG生成技术,这样我们的游戏就可以基于区块链使用这种技术。当前的解决方案是利用区块生成信息的使用(例如时间戳、现时标志、当前区块的哈希值等等)来生成随机数。尽管那些数字是由矿工生成的,但是矿工极不可能成功地改变以太坊公共网络游戏的结果,因为矿工将不得不拥有足够的挖掘力量在公共环境竞争中多次挖掘区块(大约14秒),如下所示:

  1. 矿工正在公共以太坊区块链环境的采矿过程中竞争
  2. 矿工发现现时标志,现在能够得到奖励
  3. 矿工根据游戏的获胜要求检查所生成的现时标志和区块信息
  4. 如果匹配,矿工会填充结果
  5. 否则,矿工重新开始挖掘过程,寻找另一个匹配的现时标志,忘掉以前的挖掘奖励

即使这种方法是高度可靠的,我们还是拒绝它,因为我们正在寻找一种不允许任何潜在操纵余地的模型。

RANDAO(一个分散式的自治组织,旨在产生完全分散式的随机数)是一个非常有趣的可能性,但它目前还不够成熟在这个时候实施。Joy游戏支持完全分散式的随机数字的开发,我们将投入时间研究RANDAO,因为如果它完全成熟和可靠,它将与我们的开发计划完全一致。

生成分散式的RNG数 - 敏捷方法

随机生成器必须解决以下挑战:

建议的解决方案:

数字的随机性将通过产生伪随机数字序列的同余发生器算法被引入,这将通过添加来自外界的数据输入(例如平台上的玩家移动、外汇和加密货币交换数据等)而改变。这些数据集之所以被使用,是因为它们既有意外行为,又总是可用的。这一解决方案符合许可要求,因为它可以在短时间内提供所有需要的随机数而不会影响用户体验。为了加强我们的RNG模型,我们将使用区块链技术,通过一次交易挖掘每个数字来启动双重验证。这样,Joy游戏将无法以任何方式操纵数字。

Joy令牌技术:

游戏操作

生态系统的好处和结构

通过在区块链上进行操作,用户可以轻松地识别他们的资金去向,以及结果是否能够公平地生成。用户体验是我们的首要任务,我们将提供各种各样的游戏,强大的安全性和可靠性。

除了用户利益之外,开发人员还可以从大型流动性汇合和通过在Joy游戏网络上运营提供的额外声誉中获益。开发人员将能够轻松地“证明”用户所玩的游戏,因为游戏是透明的并在区块链上。开发人员将连接到赌场,并从被玩的游戏中收集佣金,同时知道他们有一个强大的审计线索。开发人员在游戏行业中至关重要。效力于Joy游戏的我们了解游戏,并将努力在 公平回报、全力支持营销过程和更大的玩家能力方面提供最佳经验。

为了确保游戏的成功,Joy游戏为开发人员提供Joy游戏生态系统内的支持。

对开发人员提供下列支持:
开发人员只需要担心游戏的开发,Joy令牌就会完成其余的工作。

在区块链中找到平衡

当涉及启动在线赌博项目时,用户体验至关重要。Joy游戏努力工作,在游戏体验的速度和在线赌博业使用区块链带来的分散化之间找到适当的平衡点。

以太坊在当前状态下面临的可能问题

以太坊区块链并不是一个快速处理数据的最佳系统,因为“工作证明”挖掘过程每14秒发生一次。此外,由于区块链被复制到网络的每个参与节点上,因此以太坊不是设计来存储大量的数据。因此,从RNG到游戏本身的每一点都完全分散式的系统将不是最好的选择,因为会有一个显著的时间延迟,玩家不想等待几分钟才能获得游戏结果。此外,管理大量数据和处理非线性逻辑的智能合约很昂贵。

GAS价格

以太坊引入GAS价格主要是为了避免“DDoS式的攻击”,在这种攻击中,一个流氓可以创建大量的合约来影响公共网络本身的效率。这样,GAS频繁地改变其成本,目的是准确地使用智能合约需求。

总结:

Joy游戏平台是一个在速度和分散化之间现实的平衡,以提供最佳的玩家体验。填充在平台上的每一个游戏都将符合下列分散化的要求:

尽管每个游戏都由不同的开发人员提供,但是将有一个游戏接受程序(参见6.5节),Joy游戏团队将确保开发人员遵守我们的速度和分散化要求。如果游戏不符合这些要求,平台将不会填充该游戏。我们可能会包含额外的玩家KYC程序,只有经过Joy游戏验证的玩家才可以使用该平台,以便我们确保更高水平的公平竞争和法律合规。

区块链整合和情景的架构

如前所述,所有游戏的技术特点需要符合两个要求:尽量减少使用区块链造成的延迟和利用其分散化。

以下整体游戏架构在安全性、分散性和速度方面与Joy游戏平台的要求相匹配。有四个主要组件:

流程分为几个阶段:

加载阶段

我们的目标是避免在加载阶段每次下注时的验证交易时间,因为这样可以最大限度地减少区块链造成的延迟,并且会显著影响用户体验的速度。

为了满足这个要求,当游戏正在加载和配置时,用户将被要求把钱发送到所选择的游戏智能合约。

这个过程需要15秒来加载游戏并设置区块链智能合约。如果并且只有如果在用户通过KYC流程检查和验证的情况下,这个过程才被允许。未经验证的玩家将不可能向智能合约发送钱, 一个自动出错信息将指导他通过KYC程序(详情请参阅第15节)。

游戏启动过程

移动到智能合约中的硬币金额将填充到WS(钱包伺服器)中作为初始的客户钱包值。GS(游戏伺服器)可以被看作是一个类似缓存的系统,其中平台角色(开发人员、平台、客户)资金的价值将根据游戏结果而增加或减少。

每个客户的赌注将被传达给GS(游戏伺服器)以确定结果。

  1. WS建立临时钱包-客户钱包的金额将是在加载阶段投入的金额。对智能合约执行双重检查,以确保分配给客户钱包的初始金额是在加载阶段投入给客户的金额。
  2. 用户下注(例如,5个Joy令牌被放置在轮盘赌游戏中的红色处)。
  3. 使用RNG(在区块链内得到审计),赌注将被传达给GS并进行处理。根据游戏的结果,WS的钱包(客户、平台和开发人员)将相应更新。
  4. 只要用户有资金并且不想停止玩游戏,这个过程就会重复。

在网络上运行游戏的智能合约演示

    function Game(string _name, address _owner, address _registryAddress, address _ tokenAddress, uint256 _payoutRate) {
            name = _name;
            owner = _owner;
            registryAddress = _registryAddress;
            registry = GameRegistry(registryAddress);
            tokenAddress = _tokenAddress;
            token = ERC20(tokenAddress);
            payoutRate = _payoutRate;
            isActive = true;
            decimals = registry.decimals();
        }
        function activate() public onlyOwner {
            isActive = true;
            GameActivated();
        }

        function deactivate() public onlyOwner {
            isActive = false;
            GameDeactivated();
        }

        function ownerDeposit(uint256 amount) public onlyOwner {
            require(amount > 0);
            require(token.transferFrom(owner, this, amount));
            ownerAvailableDeposit.add(amount);
        }

        function ownerWithdraw(uint256 amount) public onlyOwner {
            require(amount > 0 && amount <= ownerAvailableDeposit);
            ownerAvailableDeposit.sub(amount);
            require(token.transfer(owner, amount));
        }

        function playerJoin(uint256 initialDeposit) public whenActive {
            require(!playerInGame[msg.sender]);
            uint256 potentialPayout = getPayout(initialDeposit);
            require(potentialPayout.sub(initialDeposit) <= ownerAvailableDeposit);
            ownerAvailableDeposit = ownerAvailableDeposit.sub(potentialPayou sub(initialDeposit ));
            playerInGame[msg.sender] = true;

            if (initialDeposit > 0){
                playerCurrentGameDeposits[msg.sender] = initialDeposit;
                require(token.transferFrom(msg.sender, this, initialDeposit));
            }
            PlayerJoined(msg.sender);
        }

        function announceResult(address player, uint result) public onlyController {
            require(playerInGame[player]);
            require(result <= uint(GameResult.draw));
            playerInGame[player] = false;
            GameResult gameResult = GameResult(result);
            if (gameResult == GameResult.win) {
                require(resolvePlayerWin(player));
            } else if (gameResult == GameResult.loss) {
                require(resolvePlayerLoss(player));
            } else {
                require(resolveDraw(player));
            }
            GameResultAnnounced(player, result);
        }

        function resolvePlayerWin(address player) private returns (bool success) {
            uint256 payout = getPayout(playerCurrentGameDeposits[player]);
            playerCurrentGameDeposits[player] = 0;
            if (payout > 0)
                playerDeposits[player] = playerDeposits[player].add(payout);
            return true;
        }

        function resolvePlayerLoss(address player) private returns (bool success) {
            uint256 playerDeposit = playerCurrentGameDeposits[player];
            playerCurrentGameDeposits[player] = 0;
            uint256 payout = getPayout(playerDeposit);
            uint256 platformShare = playerDeposit.mul(registry.platformShare()).div(10**registry.decimals());
            require(platformShare < playerDeposit);
            if (platformShare > 0)
                platformDeposit = platformDeposit.add(platformShare);
            uint256 profit = playerDeposit.sub(platformShare);
            ownerAvailableDeposit = ownerAvailableDeposit.add(payout.sub(playerDeposit)).add(profit);
            return true;
        }

        function resolveDraw(address player) private returns (bool success) {
            uint256 playerDeposit = playerCurrentGameDeposits[player];
            playerCurrentGameDeposits[player] = 0;
            uint256 payout = getPayout(playerDeposit);
            if (playerDeposit > 0)
                playerDeposits[player] = playerDeposits[player].add(playerDeposit);
            ownerAvailableDeposit = ownerAvailableDeposit.add(payout.sub(playerDeposit));
            return true;
        }

        function playerWithdraw(uint256 amount) public {
            require(amount > 0 && amount <= playerDeposits[msg.sender]);
            playerDeposits[msg.sender] = playerDeposits[msg.sender].sub(amount);
            require(token.transfer(msg.sender, amount));
        }

        function platformWithdraw(uint256 amount) public {
            require(msg.sender == registry.owner());
            require(amount > 0 && amount <= platformDeposit);
            platformDeposit = platformDeposit.sub(amount);
            require(token.transfer(msg.sender, amount));
        }

        function getPayout(uint256 deposit) private constant returns (uint256 payout) {
            return deposit.mul(payoutRate).div(10**decimals);
        }
    }
    

包裹阶段和支付流程

使用由友好的游戏前端促进的简单过程,用户在任何时候都能停止游戏时段并开始包裹阶段。包裹流程包括:

  1. 用户的停止请求将被填充到GS和WS上。
  2. GS将创建该时段的历史文件,文件将被复述。
  3. WS钱包的最后更新量将与复述一起发送给智能合约。
  4. 根据所发送的信息,智能合约将在区块链上改变其状态并处理支付。

游戏接受流程

我们相信,我们的方法将吸引许多开发人员和游戏建议。

为了使游戏接受流程有效率且与我们的平台相关,所有新的游戏建议将以下列方式处理:

  1. 审核代码 - 我们的专家将确保一切符合我们的安全和法律要求
  2. 根据各种指标测试游戏-时间、安全性、成本、区块链整合、用户体验等。 如果步骤I和步骤II的结果是成功的,那么拟议的游戏将会进入到整合过程:
  3. 智能合约开发。
  4. 对开发的智能合约进行测试和安全审计。
  5. 在平台上启动游戏。

一旦游戏在Joy游戏网络中被填充,所有内容都将从系统内部整合。如果开发人员需要额外的流动性,他/她很容易就能访问愿意参与提供游戏的赌场汇合。如果还有其他技术问题, 我们的团队将支持开发人员找到及时的解决方案。

支付智能合约样本

    uint256 playerDeposit = playerDeposits[player];
        playerDeposits[player] = 0;
        uint256 payout = getPayout(playerDeposit);
        uint256 platformShare = playerDeposit.mul(registry.platformShare()).div(10**registry.decimals());
        require(platformShare < playerDeposit);
        if (platformShare > 0)
            require(token.transfer(registry.owner(), platformShare));
        uint256 profit = playerDeposit.sub(platformShare);
        ownerAvailableDeposit = ownerAvailableDeposit.add(payout.sub(playerDeposit )).add(profit );
        return true;
    

在开发人员的合约中,他可以选择接受由于运行游戏而获得的利润的一部分。这是在platformShare变量中指定的。在赌场运行的每场游戏之后,开发人员将收到收入的一小部分。所有这些都直接编码在智能合约内,所以,在被玩的游戏和游戏支付之间没有等待。

区块链整合流程示例-冷冰冰的现金飞溅

虽然白皮书中包含示例代码以演示Joy令牌的功能性和实施,但我们的官方存储库可以通过以下的github链接访问:https://github.com/JoyPlatform/joy-contracts.我们将从开发的角度对代码进行注释,以充分显示我们方法的可见性和理解。如果您有任何疑问,请随时通过沟通渠道与我们的团队联系。

以太坊之外的区块链技术

以太坊还没有为游戏技术做好市场准备,因为速度和可扩展性仍然存在需要解决的问题。在本节中,我们将介绍另外两项技术,这些技术可以为我们的开创项目增加价值,并可能被整合到我们的开发计划中。

IOTA:使用DAG的分散化(有向非循环图)

IOTA是一种新型的创新分散式方法。它不是一个区块链生态系统,而是引入了纠缠的概念。纠缠实际上是一个无区块的区块链,它使共识过程成为系统的一个固有部分。


这项创新为赌博业引入了改变游戏的特点:

赌博业务的负面影响是交易确认时间。但是,交易时间直接受到活跃参与者数量的影响(因为您必须参与另外两个验证才能使自己的交易得到验证)。因此,较多的用户将减少交易时间(目前在2-3分钟之间)。值得注意的是,IOTA网络仍然是一个测试版本,免费交易特点可能会吸引大量用户,从而解决交易验证时间这个问题。这个生态系统的潜力是无限的,我们正在跟随它的发展,希望在不久的将来能够测试游戏整合。[1]

存储和托管的分散化

由于区块链技术不是用来存储数据的,分散式存储是一个开放的市场。Sia[2]、IPFS[2]和Storj[3]是这个市场的主要竞争者。总体思路是允许用户存储数据或租用在分散式环境中管理的可用存储能力。

例如,世界上很多人拥有未使用的存储能力。上面提到的竞争者提议将数据存储在一个具有高级别安全的参与者网络中,这些参与者希望通过他们的硬盘出租而获得奖励。如果一个人想存储十亿字节的文件,那么这个文件将会被分割成许多块,每一块都会被加密。然后,那些加密的片段被复制并散布在每个参与者的硬盘上。

这种模式的强大之处在于,访问文件的唯一方法是拥有文件持有者的私钥,因为不可能找到网络中所有参与者的所有加密文件片段。它以一个非常有吸引力的价格提供了强大的安全 性,它只是比普通的集中式系统稍微昂贵一点。该技术允许在任何用户的计算机上存储非常敏感的数据,因为在租户和用户之间管理的所有内容都是通过加密货币支付的。

正如第11.3节所述,我们选择在区块链存储环境中存储客户游戏时段的复述,以提供对用户旅程的完整可追踪性。在我们的模型中使用分散式存储将提供历史的安全性和强大的可靠性,因为系统不再有故障中心点。

Joy游戏正在研究在它的进一步开发中使用这个解决方案。

加盟参与

新赌场运营商往往在玩家流动性方面挣扎。而且,大型联盟公司不想与由开发人员开发的小型启动游戏打交道,因为这些启动游戏的转换率往往很低,而且玩家保留率低。因此,大型联盟机构在小型开发人员有一些交易历史之前,都不愿意与他们打交道。由于这些小型开发人员是定期而不是实时得到支付,他们经常会遇到现金流问题。Joy游戏通过我们的每场游戏付费模式轻松地解决了这个问题。客户每次玩游戏时,都会付款给游戏中的各个参与者。这确保了使用一个小的反馈循环获得一个灵活的生态系统,这个小的反馈循环甚至会进一步鼓励开发人员进行新的和创新的操作。

ICO、KYC管理和要求

为了满足我们的法律合规性,我们必须将每个投资与投资者联系起来。所有参与者,无论其投入的金额是多少,都将通过包括护照复印件在内的基本验证程序。这个过程将由JUMIO管理,JUMIO是一家值得信赖的KYC管理公司。

游戏访问、KYC管理和要求

可能会实施KYC以符合监管机构。在这种情况下,为了能够访问游戏,每个客户都必须成功地通过KYC流程。在每次成功的KYC检查之后,客户钱包的公钥将被添加到我们的系统中。一旦客户的公钥被添加,客户就可以使用我们的生态系统。然后,玩家将很容易地在公共区块链上查看他们的状态和评估他们的游戏历史。

案例研究

软件开发公司

Avent是一家想开发在线赌博游戏的软件开发公司。他们有一个惊人的可能会改变这个行业的想法。然而,因为这个想法还没有被市场测试,赌场不愿意雇佣Avent。 Avent可以在线运行他们自己的私人游戏,但这会带来许多问题。首先,Avent没有资金提供自己的私人高赌注游戏。其次,用户不太情愿地相信一家不知名的公司。另外,用户也不愿意将信用卡信息交给可以获得所有资金的第三方的想法。这意味着Avent会很难从他们创新的赌博游戏中获利。

Joy游戏用两种方式解决这个问题。首先,如果Avent在Joy游戏网络上运行,他们将接触到大量的流动性提供者(即赌场),这将解决任何流动性问题。其次,智能合约的透明和不可变性以及可靠的RNG生成算法,将使潜在的用户确信他们在Avent上所玩的游戏都是公平的。最后,由于所有的交易都是直接从用户的钱包中进行的,他们可以随时获取所有的资 金,并且更愿意尝试Avent。Avent现在能够接触到比以前更多的客户,并可以把更多的时间用于开发更多、创新的游戏。

用户

用户厌倦了不得不经常浏览许多不同的赌场和游戏室,这要求他们相信越来越多的第三方。Joy游戏确保所有交易都是可见的、规则在区块链中是不可变的、并验证其开发人员。因此,用户可以在Joy游戏网络上玩,并得到保证游戏是经过充分验证和安全的。由于在游戏开始之前没有任何资金离开用户的钱包,所以用户可以放心,他们的资金是安全的。

赌场

赌场总是在寻找新的方法来吸引用户和提高他们的游戏质量。赌场还有独立运行游戏的专业知识、资金和流动性。不幸的是,赌场不能简单地添加任意的游戏,因为新开发的游戏往往不被大众市场所接受。 Joy游戏网络带来了一个解决方案。开发新的、令人兴奋的实验性游戏的开发人员可以直接与赌场签订合同。在这种情况下,赌场是智能合约的流动性提供者, 每次用户玩游戏时,赌场都会向开发人员支付一次佣金。这是一个双赢的情形。

令牌销售

令牌

Joy令牌将作为ERC20令牌在以太坊网络上可供购买。ERC20令牌目前面临的挑战是:如果您将令牌发送给智能合同,你必须使用“批准+转帐”功能进行转账。但是,如果您将令牌发送给外部拥有的地址,您必须使用“转帐”功能。不幸的是,如果你使用这些功能犯了一个错误,那么钱就会丢失。


ERC20令牌接口的示例代码
    contract ERC20 is ERC20Basic {
      function allowance(address owner, address spender) public constant returns (uint256);
      function transferFrom(address from, address to, uint256 value) public returns (bool);
      function approve(address spender, uint256 value) public returns (bool);
      event Approval(address indexed owner, address indexed spender, uint256 value);
    }
    

我们意识到这一挑战,并正在努力确保它不会发生在我们的客户身上。我们计划升级到新 的、正在开发的ERC223标准(在它完全开发之后)。ERC223有一个新功能,如果发生上面解释的情况,钱就会自动发回给客户。

效用

Joy令牌有许多不同的用途。从最基本的意义上说,Joy令牌可以被玩家用来在Joy游戏网络上玩游戏。该网络提供一个无摩擦的奖励系统、保证的支付、吸引其他方式无法获得的联盟、消除潜在的欺诈行为并减少支付处理费用。

对于赌场和游戏开发人员来说,令牌可以用来保证运行游戏的付款和接收来自玩家的付款。赌场可以保证对所有开发人员的实时联盟支付,从而为新的赌场运营商提供与目前只提供给最大的品牌相同的高利润联盟交易。

对于依靠更大赌场来“下赌注于”游戏的较小游戏开发人员来说,令牌可以用来从提供游戏声誉和营运资金而提供游戏的赌场收取佣金。

所有合法方都被赋予安全感,他们知道不可变的智能合约,加上令牌,消除了网络上的欺诈行为。

总的来说,令牌的价值是基于用户愿意支付的,以便在Joy游戏网络上使用服务。

令牌销售结构

接受的加密货币:以太、比特币、电汇

硬限额:Joy令牌销售有一个硬上限46 340 000美元。

软限额:Joy令牌销售有一个软上限1 000 000美元。如果筹集的总额低于软限额,那么发行被认为是失败。

Timescale: Starting approximately on 20th of March 2018 and lasting for up to 31 days or before all the tokens are distributed.

超额认购:当Joy令牌发行筹集超过46 340 000美元时,令牌销售将立即关闭。有超额认购的机会。在这种情况下,超过的资金将在令牌销售结束后的15天内退回。请注意,在这种情况下不会支付利息。

失败:如果令牌销售没有达到软限额,则将被视为失败的令牌销售。在这种情况下,在令牌销售结束后的15天内,将立即终止提供的资金。请注意,在这种情况下不会支付利息。

其他风险:令牌销售涉及一些其他风险,这些风险在伴随令牌销售文件的私人配售备忘录(PPM)中有解释。这些风险包括但不限于令牌中潜在价值的损失、无法转售令牌、未能开发Joy游戏网络以及技术风险的生存能力。敦促读者阅读PPM,以获得更全面的风险解释, 并在继续进行任何投资前获得适当的咨询意见。

令牌分配

预售 20% 140,000,000
在ICO期间所出售的* 30% 210,000,000
奖励汇合(VIP等) 10% 70,000,000
在平台上售出的 23% 161,000,000
创始团队,24个月授予 12% 84,000,000
大使,资金筹集费用 3% 21,000,000
ICO赏金 2% 14,000,000
总计 100% 700,000,000

*未售出的令牌将被烧毁。

团队

首席执行官

Andrew MacDonald

拥有在主要蓝筹公司为零售和在线游戏行业工作20年的经验。已经成功地应用了专注于个体玩家的营销保留技术,并确保高质量的游戏发行来促进业务增长。是一位热衷于数据分析的敏锐的疑难解决者。

首席运营官

Mike Leys

超过34年的专业经验,其中包括30年在营销部门的经验。资深经理和资深营销专家,具有全球在线和离线营销和电子商务所有领域的知识和被证明的参与。他的行业经验包括iGaming、娱乐、移动、零售、金融服务。自2005年以来,在线上博彩领域 - 成功推出了一系列以吸引优质玩家为重点的在线游戏网站。

首席技术官

Steve Giordano Imbroll

完整的10年软件开发经验,7年商业智能、银行和财务经验。a.o., Sony, Uber & PKR科技的高度熟练的产品开发商。解决来自各个部门多个请求的专业问题解决者。公司业绩复杂性的远见者。最近着迷于游戏和证券。 索尼、Uber&PKR Technologies高级技术产品开发人员。

路线图

2017年6月
OP: 50万种子资金
2017年10月
OP:来自行业和区块链的加入顾问
2017年11月
OP:Joy游戏基金会成立 OUT:在区块链博览会上演讲
2017年12月
TECH:演示使用智能合约的老虎机 OP:申请博彩开发人员牌照 TECH:为开发人员推出Joy游戏平台 TECH:代码审核
MARCH 2017
OP:令牌销售
APRIL 2018
OP:令牌销售审核
2018年6月
TECH:游戏在Playcosmo上上线
2018年8月
TECH:扩大到固定赔率桌上游戏 OP:整合到更多平台和直接运营商

参考

[1] https://iota.org/IOTA_Whitepaper.pdf

[2] https://www.sia.tech/whitepaper.pdf

[3] https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf

[4] https://storj.io/storj.pdf

[5] https://bitcoin.org/bitcoin.pdf

[6] https://github.com/ethereum/wiki/wiki/White-Paper

目录