这篇文章主要介绍了Fomo3D 合约源码浅析 ,文中通过代码以及文档配合进行讲解,很详细,它对在座的每个人的研究和工作具有很经典的参考价值。 如果需要,让我们与区块链资料网一起学习。

https://www.interchains.cc/21698.html

Fomo3D 合约源码浅析是很好的区块链资料,他说明了区块链当中的经典原理,可以给我们提供资料,Fomo3D 合约源码浅析学习起来其实是很简单的,

不多的几个较为抽象的概念也很容易理解,之所以很多人感觉Fomo3D 合约源码浅析比较复杂,一方面是因为大多数的文档没有做到由浅入深地讲解,概念上没有注意先后顺序,给读者的理解带来困难

Fomo3D 合约源码浅析

  • Fomo3D

Fomo3D 源自上古世纪, 今天我们来看看他的源码 (实际上不是今天看的)

准备工作

环境准备 (用于调试合约)

  • git, nodejs, Chrome
  • ganache-cli, remix-ide

代码 及 IDE

安装好 Git 后, 下载源码 git clone https://github.com/reedhong/fomo3d_clone.git 安装好 nodejs 后, 使用 npm 安装 2 个东西(建议使用国内镜像源:cnpm) npm install ganache-cli -g & npm install remix-ide -g

至于 IDE 上的选择, 只要 IDE 支持 sol 语法, 如 idea 就有 solidity 插件, 亦或者 vscode 也很棒, 而且中文支持比较好, 还对于大文件 js 及 JSON 打开速度比较快, 编辑也比较流畅( idea 可能是插件太多, 各种语法解析比较卡)

源码结构

+-- interface     |    +-- DiviesInterface.sol |    +-- F3DexternalSettingsInterface.sol |    +-- HourglassInterface.sol |    +-- JIincForwarderInterface.sol |    +-- JIincInterfaceForForwarder.sol |    +-- PlayerBookInterface.sol |    +-- PlayerBookReceiverInterface.sol |    +-- TeamJustInterface.sol |    +-- otherFoMo3D.sol +-- library  |    +-- F3DKeysCalcLong.sol |    +-- F3Ddatasets.sol |    +-- MSFun.sol   |    +-- NameFilter.sol |    +-- SafeMath.sol    |    +-- UintCompressor.sol +-- Divies.sol +-- F3Devents.sol    +-- F3DexternalSettings.sol  +-- FoMo3Dlong.sol   +-- Hourglass.sol    +-- JIincForwarder.sol +-- PlayerBook.sol   +-- TeamJust.sol     +-- modularLong.sol

以上就是 reed 大佬整理的源码结构, 看到这么多文件, 心里感觉好慌, 别怕, 其实大多数文件都是摆设, 没有太多逻辑代码, 我们主要需要看的, 也就是那么几个合约, 既然如此, 我们先排除一些用处不大, 非游戏关键核心的合约

各大收款合约

  • JIincForwarder.sol (JIincForwarderInterface 类型变量的实际引用), 用于向项目基金会转账
  • otherFoMo3D.sol (游戏 activate 前必须设置的 otherFomo 变量的实际引用), 向不知道哪个地址转账
  • Divies.sol (DeviesInterface 类型变量的实际引用), 用于 p3d 分红

JIincForwarder.sol

这个合约就是向 基金会地址 转发 ether, 单独写一个中转的好处就是灵活, 这个合约可以做到基金会地址安全转移, 也就是说中途可以改变基金会的转账地址, 而这个过程需要新旧 2 个合约共同完成(旧。startMigration(新地址)–> 新。finishMigration(), 中途 旧方可以 旧。cancelMigration(), 而完成地址转移后, 新地址完全替代旧地址 ) 其中比较转账逻辑就是调用下面的这个接口对应的实际合约 的 deposit 方法

interface JIincInterfaceForForwarder {     function deposit(address _addr) external payable returns (bool);     function migrationReceiver_setup() external returns (bool); }

至于现在这个基金会的地址到底是啥, 可以通过 status() 方法查看哦

otherFoMo3D.sol

这个合约很有意思, 或者说它的背后很有意思, 大家都想知道 其他的 fomo 到底是啥, 据说不是 soon 版 至于逻辑上, 这个 potSwap 的调用时机是在玩家买 key 的时候, 而它的作用, 我认为是游戏间的奖池交换 比如说, fomolong 共有 100 个 ether 买入, 那么就会有 1% 流向 otherFomo 的奖池, 同理, otherFomo 里应该也会有这个逻辑的存在, 这么做有啥用就交给大家自己思考了

 interface otherFoMo3D {     function potSwap() external payable; }  fomo3Dlong 代码: (fomo3Dlong本身也可以是一个 otherFomo, 甚至在 真正的otherFomo 里它的那个 otherFomo 就是 fomo3Dlong 也不一定)  function potSwap()     external     payable {     // setup local rID     uint256 _rID = rID_ + 1;      round_[_rID].pot = round_[_rID].pot.add(msg.value); // 奖池金额增加     emit F3Devents.onPotSwapDeposit(_rID, msg.value); }

Divies.sol

这部分是给 P3D 分红的, 代码很简单, 就一个转账的调用, 调用时机上, 首先是买 key 的钱被瓜分时, 有它的一份, 其次当一轮 (Round) 结束后, 又会根据赢的队伍来分配奖池, 抽出一部分给到 P3D

interface DiviesInterface {     function deposit() external payable; }

当然这其中如何给 P3D 分红我还没搞太懂, 大致流程貌似是: 买 key 分红 –> 调用 Divies 的 deposit 方法, Divies 合约中此方法无具体实现(空方法, 啥也不干, 就收钱) –> 预计什么时候会有 P3D 的玩家来调用这个合约的 distribute 方法, 而 这个方法的作用似乎是将 分红转来的钱拿去投入 P3D, 然后卖出, 根据传入的百分比决定是否继续投入或重复投入和售出多少次, 最后把钱提现回来(可能就没多少了), 而钱通过 10% 的分红机制全给了 P3D 的用户??? 这一块一直不太懂, 而且这个方法的 调用时机不明, 调用时还增加了 时间限制和拥挤队列的限制。 总的将这里面就是存在给 P3D 分红的钱, 但这钱啥时候 给 P3D, 我还是没猜出来。

3 大合约

光是转账合约就感觉有些看不懂了, 真是头疼啊, 只好把不懂的放下, 留待日后琢磨。 还是先分析游戏核心代码吧

  • TeamJust.sol
  • PlayerBook.sol
  • FoMo3Dlong.sol

TeamJust.sol

首先看 TeamJust.sol , 这个是用来做权限控制的, 里面 除了与 muitiSig( 这个以后说 )相关的几个方法, 也就是管理 admin 和 dev 了, 如 addAdmin removeAdmin , 而 isDev isAdmin 则是拿来给其他合约调用(比如 playerBook 的 onlyDevs)

function setup(address _addr)    onlyDevs()    public {    require( address(Jekyll_Island_Inc) == address(0) );    Jekyll_Island_Inc = JIincForwarderInterface(_addr); }  

经过我的观察发现, 这个 teamJust 合约应该是比较后加的, 比如 fomo3Dlong 合约的激活就没有使用, 而 2 个合约不同的对于 Jekyll_Island_Inc 的赋值也让我推测这可能是较新的写法。 我也觉得这种通过调用合约赋值的方式比较好, 所以在我整的 项目 fomo3d_truffle 中, 我把 activate 函数的用户限制 也改成了 用 teamJust 来做, 而 其中的 playerBook 和 teamJust 实际合约地址也是通过 类似上面 setup 的方式 赋值, 这么做还有个好处就是可以通过 truffle 一键把这些合约部署且赋值, 而不是弄一个改源码重新编译这种测试起来比较麻烦的方式

PlayerBook.sol

这个合约主要是管理 玩家信息, 而玩家信息则分为 name, id, addr, id 是根据地址是否存在自增生成的, 而 name 则是通过 花钱注册可用于推广获取提成的! 合约内大多方法都像个数据库一样均为 crud 操作, 夹带的逻辑无非就是一些验证, 其他的都比较少, 里面比较有意思的点就是 addGame

function addGame(address _gameAddress, string _gameNameStr)     onlyDevs()     public {     require(gameIDs_[_gameAddress] == 0, "derp, that games already been registered");      if (multiSigDev("addGame") == true)     {deleteProposal("addGame");         gID_++;         bytes32 _name = _gameNameStr.nameFilter();         gameIDs_[_gameAddress] = gID_;         gameNames_[_gameAddress] = _name;         games_[gID_] = PlayerBookReceiverInterface(_gameAddress);          games_[gID_].receivePlayerInfo(1, plyr_[1].addr, plyr_[1].name, 0);         games_[gID_].receivePlayerInfo(2, plyr_[2].addr, plyr_[2].name, 0);         games_[gID_].receivePlayerInfo(3, plyr_[3].addr, plyr_[3].name, 0);         games_[gID_].receivePlayerInfo(4, plyr_[4].addr, plyr_[4].name, 0);     } }

这里是把 fomo3Dlong 的地址和名称传入, 然后就会通过接口向 fomo3Dlong 传入几个预设的玩家信息(来自 playerbook 的构造方法), 而调用过这个方法后, registerNameXxxxFromDapp 这样的方法才能不被 isRegisteredGame 拦截。 所以部署时, 这一步是必做的。

其他的几个点: 可设置的注册费用, 且费用被转到基金会; 购买 key 邀请分红总是和访问的链接的推广码有关, 只有在无推广码时, 才从历史中获取 laff, 而 laff 每访问一个推广码(并买了 key)都在改变

FoMo3Dlong.sol

主要合约啊, 先看下 所有的 state 变量

string constant public name = "FoMo3D Long Official"; string constant public symbol = "F3D"; uint256 private rndExtra_ = extSettings.getLongExtra();     // length of the very first ICO  uint256 private rndGap_ = extSettings.getLongGap();         // length of ICO phase, set to 1 year for EOS. uint256 constant private rndInit_ = 1 hours;                // round timer starts at this uint256 constant private rndInc_ = 30 seconds;              // every full key purchased adds this much to the timer uint256 constant private rndMax_ = 24 hours;                // max length a round timer can be   uint256 public airDropPot_;             // person who gets the airdrop wins part of this pot uint256 public airDropTracker_ = 0;     // incremented each time a "qualified" tx occurs.  used to determine winning air drop uint256 public rID_;    mapping (address => uint256) public pIDxAddr_;          // (addr => pID) returns player id by address mapping (bytes32 => uint256) public pIDxName_;          // (name => pID) returns player id by name mapping (uint256 => F3Ddatasets.Player) public plyr_;   // (pID => data) player data mapping (uint256 => mapping (uint256 => F3Ddatasets.PlayerRounds)) public plyrRnds_;    // (pID => rID => data) player round data by player id & round id mapping (uint256 => mapping (bytes32 => bool)) public plyrNames_; // (pID => name => bool) list of names a player owns.  (used so you can change your display name amongst any name you own)  mapping (uint256 => F3Ddatasets.Round) public round_;   // (rID => data) round data mapping (uint256 => mapping(uint256 => uint256)) public rndTmEth_;      // (rID => tID => data) eth in per team, by round id and team id  mapping (uint256 => F3Ddatasets.TeamFee) public fees_;          // (team => fees) fee distribution by team mapping (uint256 => F3Ddatasets.PotSplit) public potSplit_;     // (team => fees) pot split distribution by team

大部分都可以通过 变量名 猜出个大概, 实在不行可以搜索大致看一下哪里用了, 结合的先看一下, 其他都是各种数据, 没啥复杂的, 这里就主要看下 fees 和 potSplit

// Team allocation percentages // (F3D, P3D) + (Pot , Referrals, Community)     // Referrals / Community rewards are mathematically designed to come from the winner's share of the pot. fees_[0] = F3Ddatasets.TeamFee(30,6);   //50% to pot, 10% to aff, 2% to com, 1% to pot swap, 1% to air drop pot fees_[1] = F3Ddatasets.TeamFee(43,0);   //43% to pot, 10% to aff, 2% to com, 1% to pot swap, 1% to air drop pot fees_[2] = F3Ddatasets.TeamFee(56,10);  //20% to pot, 10% to aff, 2% to com, 1% to pot swap, 1% to air drop pot fees_[3] = F3Ddatasets.TeamFee(43,8);   //35% to pot, 10% to aff, 2% to com, 1% to pot swap, 1% to air drop pot  // how to split up the final pot based on which team was picked // (F3D, P3D) potSplit_[0] = F3Ddatasets.PotSplit(15,10);  //48% to winner, 25% to next round, 2% to com potSplit_[1] = F3Ddatasets.PotSplit(25,0);   //48% to winner, 25% to next round, 2% to com potSplit_[2] = F3Ddatasets.PotSplit(20,20);  //48% to winner, 10% to next round, 2% to com potSplit_[3] = F3Ddatasets.PotSplit(30,10);  //48% to winner, 10% to next round, 2% to com

fees 就是用来决定 玩家 买 key 后, 买 key 的 ether 怎么分配, 其中 2% 基金会(com) + 1% (otherFomo) + 1% 空投池 + fees[].p3d % P3D + fees[].gen % 收益, 10% 给 推荐人(无则给 P3D) 总结就是 14% 固定 + 86% 可设定, 86% 分 3 块( gen+p3d+pot ),所以 2 队是 56% gen + 10% p3d + 20% pot, 其他队伍类似 potSplit 类似, 固定的 48%(win)+2%(com) + 50% 可设定, 分 3 块(gen+p3d+nextround), 如 2 队的 20 gen + 20 p3d + 10 next

然后讲讲所有的方法, 简单的归类下

修饰器 isActivated()           //拦截游戏未激活 isHuman()                   //听说拦截非人类? isWithinLimits(eth)     //拦截太穷的人和 v 神 ???  ether 买     //从不同地址进的, 第一个参数是推荐人标识, 第二个是选的 team buyXid(id, team)     buyXaddr(addr, team) buyXname(name, team)  valuts 买        //从不同地址进的, 第一个参数是推荐人标识, 第二个是选的 team, 第三个是根据 key 数量计算出来的 eth reLoadXid(id, team, eth)     reLoadXaddr(addr, team, eth) reLoadXname(name, team, eth)  buyCore             // 这里就是判断了一下本轮是否结束了, 然后直接调用的 core,当然结束会走 endRound reLoadCore      // 同上, 结束的判断, 还有就是减去 gen 的金额, 再调用 core core                // 限制前100eth, 更新 end 时间, 超过0.1eth 判断空投, 更新玩家及轮次等数据, 调用2个分红方法 distributeExternal  // 给固定的13% (10% aff,2% com,1% otherFomo) 及 P3D 打钱 distributeInternal  // 给空投1% 和 gen 和 pot 打钱  提现跑路 withdraw()    结束一轮 endRound()  // pot 分成5分, win 拿48%, 2%给 com, 还有 gen, p3d, nextRound 则根据配置来分配, 其中 p3d 和下一轮逻辑比较简单, 而 gen 我还没太懂, 因为涉及到 mask 的我都没看明白( 没时间细看, 全是数学, 要慢慢推理分析 )       注册 name     //注册一个 name 用于推广获取提成, 第一个参数是 name 标识, 第二个是推荐人的标识, 第三个是是否同步到其他游戏 registerNameXID(name, id, all)  registerNameXaddr(name, addr, all) registerNameXname(name, name, all)  玩家信息相关 , 前2个一般是给外部调用的 receivePlayerInfo           //将传入玩家信息储存 receivePlayerNameList       //储存玩家的所有name determinePID                //确定玩家信息, 若无则生成一个 pid  玩家分红, keys相关 calcUnMaskedEarnings        // 实现看不懂, 不过方法作用是用来计算能提现的收益 calcKeysReceived(rid, eth)  // 根据轮次返回 用eth能买多少 keys iWantXKeys                  // 根据 key 数量返回需要多少 eth managePlayer                    // 第 x 轮时将上一轮的收益移至此轮, 仅轮次开始后第一次购买执行 updateGenVault              // 计算及更新收益 updateMasks                 // 更新被锁定的收益 withdrawEarnings                // 计算可提现的收益 

这么多方法, 我也只能列个大致作用和我看的懂的逻辑, 具体的细节等我参透再出文章

最后总结游戏大致逻辑 : 玩家买 key–> buyXxx(relaodXxx) 方法–> xxxCore –> core –> distributeExternal & distributeInternal –> 游戏结束 –> 玩家 buy 触发 endRound –> 分了钱 pot 的钱, 部分转入下一轮 –> 激活新一轮 –> 接上最开始 进入循环 !!! 当然中途可以提现自己没锁住的收益, 以及注册 name 拉人啥的。

几个有意思的类库

MSFun.sol

首先说下, 这个库是用来做多重签名的, 啥意思呢? 就是一个方法, 必须好几个(多)人同意执行, 最后才会执行。 用法如下:

 *                                ┌────────────────────┐  *                                │ Setup Instructions │  *                                └────────────────────┘  * (Step 1) import the library into your contract  *   *    import "./MSFun.sol";  *  * (Step 2) set up the signature data for msFun  *   *     MSFun.Data private msData;  *                                ┌────────────────────┐  *                                │ Usage Instructions │  *                                └────────────────────┘  * at the beginning of a function  *   *     function functionName()   *     {  *         if (MSFun.multiSig(msData, required signatures, "functionName") == true)  *         {  *             MSFun.deleteProposal(msData, "functionName");  *   *             // put function body here   *         }  *     }

大致就是先导包, 然后定义一个 MSFun.data 作为区分合约的标识, 然后再方法中使用 if 包围, if 第一句就是将之前的签名清空

MSFun.multiSig( data 标识, 需要签名的数量, 方法名称 )

最后说下此类库在 fomo 中的样子: 首先 data 照旧, 而需要签名的数量来自 teamJust.sol, 它的定义是构造是初始为 1, 以后每 add 一个 admin 或 dev 就把对应的 requiredSignatures 加一, remove 同理, 减一。 所以在部署时不改代码的话, 只要满足对应的身份限制, 加了这个 MSFun.muitiSig 的方法默认是一个人调用就能执行

SafeMath.sol

这个没啥好说的, 操作金额必备, 听说狼人杀就是少了这个被攻击的(整形溢出), 也许可以不懂怎么攻击, 但一定要懂怎么防范, so

/** * @dev Multiplies two numbers, throws on overflow. */ function mul(uint256 a, uint256 b)      internal      pure      returns (uint256 c)  {     if (a == 0) {         return 0;     }     c = a * b;     require(c / a == b, "SafeMath mul failed");     return c; }

如你所见, 简单的判断即可确保不会由于溢出导致数据错乱

F3DKeysCalcLong.sol

我只能猜到作用, 至于完全理解… 没上过大学的我瑟瑟发抖

keysRec(curEth, newEth)         // 第一个参数就是using 后的调用方, 第二个参数是 准备花的 eth, 如我花0.01 eth , 用 round_[rId].eth.keysRec(0.01 eth); 得出的就是当前轮次时0.01eth 能买多少个 key, 注意返回的 keys 很大, 1个 实际上是 1e18 吧,  ethRec(curKeys, sellKeys)       // 同上, 输入想买的 keys 数量, 返回当前轮次 keys 基数下购买 keys 需要花的 eth keys(eth)                       // 根据 eth 计算可得多少 keys eth(keys)                       // 根据 keys 计算需要多少 eth

bundle.js 中, iWantKeys 逻辑

count = BN(parseInt(count) * 1e18) let priceQuotation = await JUST.Bridges.Browser.contracts.Quick.read('iWantXKeys', count)

keys 和 eth 应该是对应的, 而 eth 的变化规律如果画图的话应该是 指数级上升? 可以画成函数看看

部分转自网络,侵权联系删除www.interchains.cchttps://www.interchains.cc/21698.html

区块链毕设网(www.interchains.cc)全网最靠谱的原创区块链毕设代做网站 部分资料来自网络,侵权联系删除! 最全最大的区块链源码站 ! QQ3039046426
区块链知识分享网, 以太坊dapp资源网, 区块链教程, fabric教程下载, 区块链书籍下载, 区块链资料下载, 区块链视频教程下载, 区块链基础教程, 区块链入门教程, 区块链资源 » Fomo3D 合约源码浅析

提供最优质的资源集合

立即查看 了解详情