f3d源码解读

Fomo3D 源码解析, 部署指南

https://www.meiwen.com.cn/subject/efntbftx.html

原文链接

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 的变化规律如果画图的话应该是 指数级上升? 可以画成函数看看。