Juicebox浅析与合约代码走读(一)
0xf41a
January 24th, 2022

Juicebox v1主要流程梳理

最近一段投身于PeopleDAO的建设,发现很多人对$PEOPLE的生成工具Juicebox不是很了解,所以决定分析一下Juicebox的流程与合约代码,方便大家了解PEOPLE代币的诞生以及安全性。由于时间精力有限,难免会有不少不对的地方,欢迎大家指出,这里就当抛砖引玉了,闲话少说,下面进入分析:

$PEOPLE的合约地址:0x7a58c0be72be218b41c608b7fe7c5bb630736c71

产品流程体验:

在开始分析代码之前,我们通过在juicebox测试环境创建一个项目,先来大致还原一下ConstitutionDAO的诞生过程:

1,首先给创建一个新项目,填项目信息

2,然后设置筹集资金的数额,以及筹资的时长。Juicebox筹款是按周期来的,你可以设置一个周期的时长以及筹集资金的数额,可以分几期来筹资。

3,资金分配:这里主要是可以把筹集的资金直接打一部分到特定的账户或者其他Juicebox项目

4,保留代币:默认情况下一个项目你支付1ETH获得100万对应的Token,但是如果把Reserved tokens设置为50%的时候,1ETH就获得50万的Token,另外50万默认给项目拥有者,也可以有项目拥有者分配给其他钱包。后面可以根据具体事例来分析:

5,重新配置:这里主要对下一轮筹资周期的策略

6,激励措施:这里主要作用就是决定是否要对早起的捐赠用户给多的Token奖励,先用默认设置,后面可以根据具体事例来分析

7,受限操作:

暂停期间,项目不会再收到直接付款;

允许项目所有者手动铸造并发送任何数量的代币。

8,项目创建之后,确认信息没有问题就可以创建一个项目了

这样点击发布就发布了一个DAO项目了,不过此时项目的ERC-20的代币合约实际上还是没有创建的,需要手动点击Issue来发行代币;

9,发布之后,持有人点击Issue ERC-20 token就会发布一个代币

创建发行代币之后,用户向项目捐赠ETH就能获得ERC-20代币了。

下面就根据上面流程,简述一下ConstitutionDAO(以下简称CDAO)生成的合约调用流程,因为CDAO使用的V1.0版本,所以先分析V1.0版本:

项目创建调用过程:

TerminalV1.sol: 这个合约是主要与用户交互的合约,包括创建项目(deploy)、捐赠(pay),赎回(redeem)等都是通过这个合约调用的;特别说明下,这个合约有个升级方法migrate,一般情况下,这个方法是会导致创建的项目有增发的风险的,但是$PEOPLE因为项目发起人放弃了项目的主权而不再存在这种风险,后面篇章会详细说明为什么$PEOPLE是安全的。

Projects.sol: 这个是项目的实体合约,这个合约本质是一个ERC721协议,你可以把它当做一个特殊的NFT,只是这个NFT不是代表一个jpg的主权,它代表的是Juicebox上面一个项目的主权;CDAO就是通过把这个NFT发送给黑洞,从而放弃了$PEOPLE的主权。

TerminalDirectory.sol:这个合约看它名字就知道,它是一个记录Project→Terminal的数据结构;因为Project对应的Terminal版本有可能通过Terminal#migrate,所以才要用这个机构记录起来。

FundingCycles.sol:这个合约主要记录与管理筹资周期。

ModStore.sol: 这个合约主要记录Project的payout模式与ticket的模式,具体作用后面篇章分析。

流程图中标红处说明:

1,CDAO使用的是GnosisSafe多签钱包与Juicebox交互,正好PeopleDAO的国库也是用多签钱包,以后会专门分析GnosisSafe合约;

2,这里Projects调用的是ERC-721的mint,并把mint出来的NFT传递给了项目创建者;

3,项目创建时,会把创建的Terminal合约与Project的ID关联起来,记录在TerminalDirectory中。

代币发行调用流程:

TicketBooth.sol:这个主要处理与Token相关的操作,例如:issue(发行)、print(给捐赠者发放代币)、redeem(捐赠者销毁代币赎回ETH),注意除了issue是由合约创建者直接调用之外,print与redeem都不能钱包地址直接调用。

Tickets.sol:Token的实体合约,本质是一个ERC-20:

上面是Tickets合约的源代码,其中print负责代币发放、redeem负责代币赎回;从权限修饰(onlyOwner)可以看到只有合约拥有者可以调用,注意:这里合约拥有者并不是指项目的拥有者,而是Tickets的创建合约TicketBooth。我们的$PEOPLE代码上就是这货,肉眼看这货貌似不怎么安全,但是为什么又说它是安全的,咱们下回分解;

捐赠流程:

赎回流程:

注意:以上针对分析的主流程(CDAO),其他分支流程并没有全部列出,后面会根据具体场景分析分支流程

现在Juicebox主要流程以及CDAO产生过程已经基本梳理清楚,下一期专门分析一下合约之间的调用权限,重点是梳理$PEOPLE的安全性。

关于我:

我叫duloti,是一名web3.0开发者,目前正投身于PeopleDAO的建设;正在为PeopleDAO开发NFT、官网。

Github:

Twitter:@duloti53

官网:

我们也正在建设一些subDAO比如:PandaDAO,LanguageDAO等;未来还会开发一些有意思的web3.0项目;欢迎加入PeopleDAO的discord,一起建设,一起玩:

参考链接:

Juicebox正式环境地址:

Juicebox测试环境地址:

CDAO创建地址:

Juicebox v1架构:

Arweave TX
ILltBi7-Aq1e0XoX5SZGzpscyhPhk1J-b2H6YckTCwE
Ethereum Address
0xf41aab66e7771BdfcCf43953b7843873d9bB74f4
Content Digest
5e-STjbKdSs3ajm1Cz4hGArxTTNWe7CqIhZuVQrDbnk