21Day Collective （TBD）

缘起

上个月，上海区块链周的时候，Tina 找我吃饭，说想在 Devcon 期间举办一场 DeFi WTF 的 Talk，然后给我看了一下她起草的一份粗略的 Agenda。时间非常巧，首先当时我很早就准备了去大阪的行程，但是还没有买到 Devcon 的门票，其次，当时我正在看 Zepplin 给 Compound 2.0 所做的审计报告，正准备写一些关于 DeFi 合约开发的东西，Tina 的这份 Agenda 看起来十分的 Promising，内容涵盖的都是我一直在思考但是考虑不清楚的东西，我和 Tina 说，要想讲好这些主题，可十分不容易，只有在这个行业里真正的从业者才能解答，你得请到 xxx yyy 还有 zzz 不可。Tina 自信满满的说到，这些我都考虑到，你看这 …

执行

https://orange.xyz/p/402
一个只存在15天的“公司”

有一个关于米开朗基罗的段子，好像是（有人记得来源吗？）
艺术家并不是把石头雕塑成自己眼中想要的样子，而是还原已经在这块石头内部的那原本的雕塑。在 21 天刚开始的时候，事实上在看到了那份 Promising 的 Agenda 之后，我就已经了想像出 21 天之后她开花结果时的样子了。我个人对这种 "21 天的公司" 也非常感兴趣，而且这一次想用 21 天筹备出一场信息量这么足的活动，也是比 Hackathon Project 更有挑战，也更有 Impact 的事。

剩下当然是执行层面的问题。说起来这种密度和规格的会议，像是 Coscup，和 Sitcon，都是需要提前一年开始零筹，时间较紧的如 CTAPC，廖老师也是给了我们 3 个月的时间来 Call for Paper，但是现在我们只有 21 天的时间，不仅要着急联络甚至还有开发上的工作，而且还时不时的会添加需求，其实能不能 Deliver 我们都打一个问号 …

幸运的是，Tina 在周末的 Polkadot Hackathon 上拿了奖金，并且完成了一个广告牌的前端交互原型。

关于广告牌，大概这是我们目前能想到的最适合实践哈伯格税的应用场景，我们之前自己也做了一个基于 EOS 的版本，以太坊上我们想到的是：
https://github.com/BlockchainEconomicsStudio/anadvertisementboard

但实际跑了一下，发现这个合约问题满多的。（甚至跑不起来）
于是找到了原文里 credit 的艺术品合约 (TAIAOS a.k.a. This Artwork is always on sell).

在这个 Repo 的 Readme 中，Credit 了一个 更早的来源，还是 ETH-SF 的 Winner。

所以哈伯格税最早应用场景看来就是广告牌！（事实上更早的时候，Chenpin 之前在 TPE 也讲过类似的东西）

Whatever，这里我们还是从 TAIAOS 开始。

TAIOS 的合约分为两个部分组成，看它的 deploy 方法 ，

​​​​deployer.deploy(Artwork, "This Artwork Is Always OnSale", "TAIAOS").then((deployedArtwork) => {
​​​​  console.log(deployedArtwork.address);
​​​​  return deployer.deploy(ArtSteward, artistAccount, deployedArtwork.address);
​​​​});

可以看到是先部署了一个 Artwork 合约，这是一个稍微魔改了一行的来自 Zepplin 的 NFT 合约，标注了 tokenID = 42 的 Token 作为艺术品。接着部署了 ArtSteward 合约，利用哈伯格税的机制作为拍卖行。

有了合约之后，接下来考虑前端的部分。

首先找到的是 CryptoHero 和 Dapdap，
https://github.com/cryptohero/cryptohero-frontend
https://github.com/Dasdaq/Dasdaq-web-old

不过这两个仓库的 Web3 版本都有一点落后，网上找了一圈，发现好多 Ethereum Hackathon 的 Project 其实都运行不起来。所以最后这块只好自己重新写。

写好了之后我们很早就放出了一个测试网的版本供大家 preview，反馈的结果是，从以太坊上拉数据的动作太慢，交互体验很差。

于是我们的小伙伴驴子就起了一个 Wrapper 和 后端，来实时监听并缓存链上的结果。

To do list

当然整个执行下来，我们还有非常多不足的地方，

第一是 CI/CD。
因为整个过程的 Agenda 和需求一直在变动，网站的更新可能会非常频繁，在这种情况下，提前搭建一套可用的 CI/CD 方案几乎是必须的。

第二是 QV Tools，既然是 21 Days Collective，我们希望可以更多的 involve 社区的参与，甚至议程本身都希望是自筛选的，而实现这些就少不了各种投票工具和机制设计。

第三是 Incentive Plan，我个人是不看好完全用爱发电的机制的，拥有更好的 Incentive Model 可以让 21 Day Collective Plan 更好的具有抗脆弱的特性。