district0x 的开发进展和产品变化
在过去的几周，我们团队一直致力于实现我们以前在 IPFS 的 CLJS 包装器上的工作以及用于我们的0x 包装器的 fx 库。在不久的将来，随着几名工程师加入我们团队，我们还将努力转向规划一系列更小、更具体的任务。
除了所有这些，我们已经开始考虑最初在模因工厂中承诺的设计模式 - 特别是模因本身是否以ERC20或 ERC721代币为代表。下面我们将探讨这些折衷方案以及我们打算如何制定它们。
d0xINFRA 更新
- 进展中的
上次，我们讨论了我们在尝试开发用于 0x 连接库的本地 CLJS 包装时遇到的问题。在对 shadow-cljs 编译器的许多问题进行故障诊断后，我们成功完成了 0x 连接库，现在开始构建一个库来覆盖0x所有必要的重构效应。这项工作将继续进行下一次更新。 - 完成的
在之前的更新中，我们提到了我们对 CLJS 库所取得的进展，我们可以我们所有技术堆栈中使用它来管理 IPFS。但是，为了在浏览器设置中正确使用这个库，有必要把它拆开并尽可能轻。经过一些广泛的改进和测试之后，我们很高兴能够有效地完成此项任务。
此外，我们在 GraphQL 模块上为未来前端开发所做的工作已被广泛记录。这将有助于地区的快速建设，这不仅适用于我们，也适用于其他开发商。
模因工厂更新
- 进行中的
正如文章前面所提到的，过去两周大部分时间都是为了对模因 工厂进行一次轻微的重新设计。 最初，我们计划允许模因工厂的用户发布模因 ERC20代币。
这背后的基本推理非常简单，归结为两个折衷方案。 首先，从最根本的意义上讲，在模因工厂上发布的模因是可替换的。相同模因卡的单个实例之间没有功能上的区别（除了发行顺序，例如“＃3/100”），因此每个模因都可以有一个唯一的 ERC20代币来覆盖它的每个实例。通过将代币的小数点附加到可能的最小数字位置，可以防止每个模因的细分，这些模因强制每张卡保持为一个“整体”。
使用 ERC20s 的第二个好处是简单得多 - 它的成本更低。 在大多数情况下，如果发放 ERC20的供应量为1，则需要花费相同数量的 gas，因为如果是100万份，就要花费100次 gas 费。相比之下，ERC721 具有相关的 gas 成本，每个代币发出，极端限制情况下可以很容易地遇到以太坊的硬 gas 费限制。
那么考虑到这些重大的折衷方案，为什么还要考虑 ERC721呢？ 简而言之，它是最接近代表独特数字收藏品的标准。随着围绕 ERC721标准的元数据在钱包/ dApp 生态系统中的正式化，这些代币将具有越来越明显的外观和感觉（ERC20的趋势不太明显）。 模因本身就需要利用他们的在线视觉组件。
最终，当我们开发了大部分智能合约并开始剔除我们认为对于 Dank 注册表来说是一个合理的起始参数集的时候，我们发现用一些小角落使用 ERC721可以比 ERC20更好地实现目的。此外，通过将最终的发布行为置于模因创建者身上（而不是在他们被注册表接受后就立即自动制作模因），除了二级市场，我们也可以消除一级市场对模因工厂的需求。 在这种模式下，模因创造者有权发布注册表允许选民有一定数量的模因，并且随后可以将它们放置出售，所有这些都是使用他们自己的时间和 gas 费成本。
接下来是什么呢 ？
将我们的智能合约基础转换为 ERC721模型所需的工作已经开始，预计将继续进行下一次更新。此外，预计模因工厂社区设计大赛的开场时间会缩短。 我们迫不及待地想看看你们为我们准备了什么。
