Defifa 工作报告 - Jango
我们将运行一个 NBA 季后赛版本的 Defifa，NFT 的 mint 开放时间相对较短。
我们还会尝试使用生成艺术组件和一些 HTML 渲染的 SVG 文件来制作新的 NFT。在合约方面，我们将启动一个类似 NFL 的锦标赛，但新增了一个让用户可以在铸造时委托认证投票的功能，以便他们游戏后期不必再亲自回来参与认证投票，只要他们愿意把这个责任委托给类似 Defifa 球童或其他值得信任的代表。
从前端的角度来看，我们会用全新的创建流程来部署游戏，但整个流程中仍然存在一些问题，因此我们正在加紧改进，希望能尽快推出这个锦标赛。
这个锦标赛并不是为了吸引高关注度、高流量或高参与度，更多的是因为我们觉得 NFT 很酷炫，锦标赛很有趣，同时我们也想尝试一些新的东西。
我们将通过一个开放使用的创建流程来推出这个锦标赛游戏，任何人都可以访问 create.defifa.net 来启动自己的锦标赛。
项目标签报告 - Peri
我们最近正式发布了项目标签，意味着项目方可以最多为项目选择三个标签。
项目标签的好处如下：
- 标签将显示在项目标题和搜索结果中。这是一个很好的附加说明，有助于为项目信息添加一些背景情况。
- 在探索页面还可以按标签来筛选项目，以及搜索特定类别的项目。
- 允许我们在首页或应用的其他位置展示项目供人们浏览。
除了项目标签，我们增强了搜索功能。现在我们不仅可以通过项目句柄搜索，还可以通过名称和项目详情的文本内容搜索项目。
Bananapus 问答环节 - Jango, Nicholas 及其他成员
为什么要使用L2？动机是什么？
- 理想情况下，我们会达到这样一个点：人们可以在支付项目时产生更少的 gas 费，这也意味着项目可以更好地利用他们所接收的资金。因此，第一要务是如何让最频繁的交易，也就是支付交易变得更便宜。
- 还有其他各种操作，例如项目部署、重新配置和支出，在非 L1 环境下时，这些操作都会变得更加容易和便宜。
- 在各有特色和工具的 L2 里寻找新的受众和社区进行建设和合作，令人倍觉鼓舞。
考虑Juicebox如何在L2上运行时，我们需要思考很多问题。
通过我们版本控制的经验，我们知道管理多个金库是很困难的，因为每个金库都是一组资金，它们都可以接受资金并各自发行代币，这些代币又只由发行的金库提供价值支撑。
L2 Juicebox是要解决与 L1 Juicebox 协议相关的特定问题，还是只是在 L2 上运行一个功能相同的实例？
我们过去一年在版本控制工作中收获良多，特别是在同步和管理不同金库方面。管理不同金库可能会代价昂贵而又微妙，但如果我们做得好，它可以带来非常巨大的好处和便利。尽管代价不菲和存在脆弱性，但希望我们能持之以恒并实现目标。
此外，保持各个金库之间的同步将会非常微妙，特别是当它们发行的资产 1:1 可以互相兑换时，就像我们在V1、V2 和 V3 金库中的 JBX一样。当涉及到跨链资产、桥接和小批量资金未必整齐对应时，这个问题将变得更加棘手。
公交站比喻
在 L1 和 L2 之间进行资产桥接，可以像定期公交运营一样进行。
我们可以设置一个桥接层，允许人们在一定时间段内进行支付，就像公交车按照每日时间表来回穿梭于 L1 和 L2 之间。公交站将支付来回的所有 gas 费用，所以参与人数越多，单位成本就越低。
捐款通常是相同金额的，付给相同的项目，返回相同的代币数量。虽然支付者不一样，但它们看起来都相同，因此 L1 项目可以将它们总体视为一个交易。
在 L1 项目中产生的相应结果，如分发项目代币、NFT等等，将随公交车返回到 L2，那里的支付者就可以按相应的份额来领取。
利弊得失
- L1 金库可能按固定周期来运作，而支付跨链公交可能会导致时间错配，因此通常跨链操作会有一些时间上的制约因素。
- L1 团队使用的支付数据源可能使两边的结果难以对等。
- 项目代币和任何资产都必须具有 L1 和 L2 版本，只能通过公交站进行互通。资产将由公交站来托管，以发行相应的 L2 版本，但又不会有任何 L2 金库来支撑。如果代币用于 Snapshot 的投票，其 L2 版本应如何进行对应？
Filipv 认为，让 L1 和 L2 上的项目总体上各自独立是一个好的选项，但通过优化跨链支付体验，让人们不用在多个 Rollup 上都部署相同的项目，而是不同链上部署不同的项目，但又可以互相进行支付。他补充说，这个方案的另一个好处是减少了理解现有 Juicebox 概念的认知负担。他还认为，公交站方案的最大弊端是在我们的培育用户流程中增加了一些额外的复杂性。
Jango 认为，公交站跨链方案现在还不适宜进行实现。此外，他认为，将社区中的机会和风险分隔开来，赋予个人而非组织更多的权力，将令工作更加有效。
鉴于协议已经有保留代币和支出的功能，Bananapus 方案的目标是尝试将保留 JBX 代币分配给生态系统中的项目和项目成员的群体，而不是发送到目前由多签进行管理的 DAO 钱包 dao.jbx.eth。目前，我们还没有找到一种可以直接将保留代币分配给社区成员的方法，但值得进行尝试，因为这个举措非常重要，可以让个人更广泛地参与社区治理。
L2 运营和 L1 协议改进的优先顺序
Nicholas 在周会上指出了 Juicebox 协议的不足，具体如下：
- 作为一个号称自动化可编程的金库协议，它实际上没有为分配支付提供任何解决方案来减轻项目方的负担；
- Juicebox 声称通过预编程的链上支付增加透明度，可以添加延迟策略，让社区成员为任何不利变化做好准备，但在现实中这方面完全不是这回事；
- 尽管协议具有各种模块化，但到最后人们还是只能用 ETH 进行支付，没有任何 ERC-20 终端可以使用。虽然项目间互相支付时具有发行代币和代币交换的网络效应，但事实是，人们并不能用这些成员代币来主张任何权利。
Nicholas 认为，我们应该优先改进协议的可用性，而不是将重点放在扩展到当前没有太多需求的 L2 环境上。
Jango 表示，他对在 L2 上进行实验感兴趣，是因为有几个项目提出这样的需求。我们很难提前了解改进协议的最大收益在哪些方面，除非人们提出并阐明他们的具体需求。
Nicholas 认为，尽管通过扩展到 L2 来降低 gas 费用是好的，但它并没有解决我们的根本问题，也就是与受众群体间的互动。因此，他建议我们在当前阶段将重点放在改进当前的协议上，而不是将重点放在扩展到 L2 上。
Juicebox 是什么
Jango认为，Juicebox是以太坊上的一个数据模型，提供了一种为住在在以太坊区块链上的数据建模的办法。它离不开 JuiceboxDAO、Peel、WAGMI、ConstitutionDAO 等在其之上构建的 DAO。从某种意义上来说，它只是一个数据模型的表达形式。人们可以在该协议之上构建许多可能性，该协议由一些相互关联的功能来定义。
Jango认为协议更多地作为数据层而非一个寻求市场接受的产品。我们的目标实际内源性增长，而不是要去说服其他人积极参与研究这个协议。比起为了特定的发展任务，他更钟情于与志趣相近的人一起构建。
Nicholas认为，该协议需要易于理解并解决特定的问题。他认为，金库模型不够完整，对人们的作用不大。Jango认为，从当前存在的工具来看，Juicebox 的确解决了某些人群的金库需求，但需要给项目方更多时间来进一步改进。Jango 认为有许多创造性的方法来帮助项目方和解决问题。
Bananapus 是什么
Bananapus 是一个计划中的项目，具有特定的方案，试图提出一个论点，即 Juicebox 需要解决的首要问题是实现链上治理或培育跨链组织，以及努力帮助项目更好地将代币分配给其他成员群体。
Nicholas认为，Juicebox 与 SAFE 或Uniswap 相类似，是一个具有某些功能并为大众服务的协议。但目前，他并不认为该协议很好实现了它号称的自动可编程金库功能，也没有任何筹款资产支出保证的解决方案。他感到失望的是，所有这些问题都被忽略了，没有进行讨论。Nicholas 建议，合约团队在增加协议的复杂性例如扩展到 L2 之前，应优先解决这些问题，。
Filipv认为，DAO 需要一种更好的决定问题优先次序的办法，因为提案并不是能准确反映 DAO 的兴趣所在，尤其像 Bananapus 这样的提案。
Jango 认为，我们目前拥有创造性的自由，来决定我们下一步将要采取的步骤，人们既可以使用现有的工具套件，同时也可以建议使用他们选择的特定用途的应用。启动 Bananapus 项目的决定并不是仓促做出的，它已经进行了一段时间的讨论。我们都有过 gas 费用飙升的经历，这个时候很难与项目进行交互，未来我们可能会看到更多的 rollups 或特定应该的二次网络的出现，因此最好我们能在战略上提前做一些繁复的工作，并思考 Juicebox 如何在这些环境中发挥作用。
通过提交 Bananapus 提案，Jango 试图建议我们的社区联合起来，提出我们多链运作的建议，同时我们不应以组织集体的形式参与这个项目。我们应该鼓励那些想在其他链上运行协议的人，并给予他们支持。
Jango仍然相信，如果该协议有用并被证实是一个持久的数据模型，人们最终会考虑使用它。但他也愿意与大家一起合作，决定工作的优先次序，并进行深入的研究。
关于反馈意见被忽略的忧虑
Nicholas 表示支持 Bananapus 项目，但他也指出，如果 Juicebox 想实打实地提供我们宣称的解决方案，首先要解决一些我们的以太主网协议存在的问题。此外，协议成功需要一个充满活力的开发者社区，但除了我们的合约团队和 Jacopo 之外，似乎我们并没有什么活跃的开发者社区。他还觉得，一直有反馈觉得协议非常难理解，这些意见本应早被纳入到协议架构的讨论中。
Jango说，协议是一件经历了演变并具有各种功能和灵活性的工具，一路走来需要做出很多决策，但易用性对于协议上运行的不同项目来说可能意味不同。随着我们版本管理工作的完成，现在我们处于一个非常好的状态，来确定需求的各类，以及我们如何创建合约来索引协议，获取信息，汇总它们，然后将它们一起提供给用户或开发人员，让他们按照自己的意愿使用。
他坚持认为，如果没有逐步编写或调整，很多功能在我们当前的 L1 协议上是无法使用的。一开始功能很单一，我们互相倾听彼此的想法并分享彼此的担忧，然后功能开始形成并演变，直到我们实现目前的状态。Jango 确认我们不会忽略要求简单化的需求，也不会因为技术上炫技就故意把事情复杂化，更不会通过 Solidity 故弄玄虚来彰显自己的 Solidity 水平或其他原因。我们只是为了追求更优化的、更合理的方法。
Jango承认，在降低使用门槛和简单化上面，我们还有很多工作要做，但至少这种思路是正确的，所以我们应该聆听人们的需求并尽量满足它们。我们不需要从头开始，我们有一个坚实、经过测试和经过考验的代码库可供借用。他强调我们没有忽略或忽视某些需求，只是有我们能够达到目前的地步需要满足很多前提条件和更重要的考量。这是一个漫长而耐心的努力，需要做很多工作，但他表示构建下一个项目时将更多考虑更多的反馈。
Nicholas 认为，我们的共同方向都是让人们能够创建链上运营的项目，更偏向于长期发展，而不是那些昙花一现的知名筹款活动。通过提供 Nance、Blunt 和 JBM 等不同的工具来支持持续性项目的创建，这样开源项目就会选择在 Juicebox 上运行，因为这样他们可以获得实质性的东西，值得承担 2.5% 的费用和其他管理成本。
但他认为我们目前应该通过关注开发人员的想法、了解他们在理解协议工作原理时面临的挑战，来设法解决协议中存在的问题。他还认为，如果 L1 未能获得开发者关注，那么把协议转移到 L2 也不会让这一问题得到改善，而且也解决不了协议面临的缺乏蓬勃发展的社区这样的核心挑战。
Jango解释说，由于我们过去一年一直在进行版本控制工作，在这期间让人们在行将更改的协议之上开发是不明智的。他认为我们需要吸引开发者，或寻找有大想法并寻求合作的人。我们需要花费大量精力来厘清人们可以开发的各种项目，并提供 JBX 非常简单的接口，让他们初期无须雇用前端开发人员。
到目前为止，我们的目标是安全性、稳定性和达到一个有效及去风险化的状态。JuiceboxDAO的头等大事是安全性，只有这样才能继续去做任何别的事情，我们可以在坚实的基础上建设，充满信心地向上攀登而不用担心梯子会不会倾倒。在版本控制工作完成之后，我们现在已经达到了这一点。我们现在可以自信地把这个信息传达给人们，并通过构建项目并一路记录下创建的详细过程以供人们参考。
Nicholas 认为，在某种程度上，协议开发实际上对于任何不直接参与其中的人来说都非常不透明，而其中的决策显然是专业人员决策，但它似乎与DAO相信的运营使命有所脱节。
他还认为，在加密货币或软件产品开发中，实际上有两种哲学方法:
- 更注重创建较小的产品，先测试一下市场的反应，看看哪些能够被接受，再在此基础上来增加复杂的功能。这在某种程度上也是 Juicebox 一直采取的方法。
- 更宏大的构建方式，我们之前没有开展过类似的讨论，关于我们正在采取的构建风格、我们正在选取的构建方案、我们是否要对我们的想象力做出长期大胆的赌注、需要什么样的模块化，或者我们是否希望进行更小的迭代并针对市场进行测试以获得 PMF（产品/市场契合度）等。
Nicholas 认为，从 Jango 的意思看，他并不是那么关心 PMF，他更关心的是怎么在 EVM 上构建方便且非常具有表达潜质的数据层。
Jango 说，从 V1 到 V2 的演变，希望能使我们将来的迭代不再需要动辄整个协议来进行，而是更多视乎市场反应的小范围快速迭代更新。他承认，有些他觉得是经过讨论的事情，在其他人看来更像是不够公开透明的个人决策。我们可以通过编写文档、周会分享、以及更加重视优先事项来把事情做得更好。
其他成员的看法
Filipv: 我认为这是一个重要的讨论，谢谢你提出了所有的这些问题，Nicholas。我希望我们能够更多地就协议开发、前端开发和优先级等方面展开实质性的讨论。我发现无论是周会或者 Discord，我们的讨论很快就会变得非常哲学化和抽象化，我不知道这是否是一个很好的趋势。我支持很多时候对待事物可以从意识形态的角度切入，但我认为在某个层面上，当涉及到某些事情时，我们需要更务实。我不认为我们可以忽视很多事情的实际现实，比如 Nicholas 提到的开发者接受度。我希望以后会有更多像这样的讨论。
Aeolian: 看起来大家对所有这些小组件的目的没能达成共识。我们每个人是否对协议的目标是什么达成一致？这个目标是提高使用率吗？还是像Jango所说的，我们只是为了构建非常安全和优化的协议，以便在用户在此基础上搭建其他东西？
作为 JBX 的持有者，当我看到这个 Bananapus 提案时，我想的是：如何评估这个提案？我用什么标准来投票赞成这个提案？它会增加协议的使用率吗？它最终会带来更多的收入，或是其他完全不同的事物？还是说，我们投入的人力物力非常大，但它带来的价值可以让这些投入显得合理？也许这些在某种程度上只是我个人的观点，我觉得我们在理解我们的目标这个基本层面上没有达成一致。
Filipv: 我通常也是根据 JuiceboxDAO 长期存续的可能性的最大化来评估提案的，因此涉及安全性的问题优先级是非常高的。但我们也不能太过于偏向某一个方向。只顾收入最大化可能会毁掉整个生态系统，不利协议的长期存续，但是理想化地完全忽略收入和可持续性，导致金库清空、人们不再贡献，然后生态系统逐渐消失，这样也是不妥的。我认为在 DAO 中发生的很多事情都没有顾及这个方面，所以我很想听听其他人如何评估这些事情。
STVG：从我的角度来看，我们评估提案时关注的大部分内容都是如何通过 Juicebox 增加使用量和创造收入，以便我们所有人都能继续为 DAO 做出贡献。有一段时间，我们的关注集中在这些体量比较大的筹款活动，现在我们开始着眼于更小的项目，这样人们可以在 Juicebox 上运行初创企业、实验等等。
我认为我在某种程度上既同意又不同意 Nicholas 和Jango的看法。我确实认为这是一项重要的实验，但同时我也认为我们现在已经有很多实验，也许现在是时候来关注我们的主要功能了，从而生成更多的协议项目，希望能产生更多的收入，这样我们可以继续建设，同时也对开发者和项目创作者更有吸引力。
