在 PopCraft 游戏中，每一步操作都需要上链，这导致交互时间较长，用户体验较差。

理想情况或目标：

通过在 Solidity 合约中使用零知识证明 (ZKP) 加速游戏性能。具体目标是确保游戏的过程不上链，但同时防止作弊。玩家的每一步操作会生成 ZKP 证明，最后将结果证明发送到智能合约进行验证。

研究过程、思路与挑战：

• **游戏过程与结果的防作弊：**仅对游戏结果生成 ZKP 证明是不够的，因为游戏的过程同样存在作弊的可能性。因此，既要对结果生成证明，也需要对游戏过程进行验证。

• **逐步生成证明的技术挑战：**为了防止作弊，希望可以在游戏的每一步操作后生成一个 ZKP 证明，最终在游戏结束时将最后一个证明上链进行验证。这个过程中，每一步的证明都会依赖于前一步的证明，直到游戏结束为止。但难题是：

  • 每次生成证明时需要依赖前一步的证明，这使得验证过程复杂化以及不确定能否实现，并且验证是在合约端做，第二次生成证明时又如何去验证第一步的证明是正确的。

  • 在智能合约端验证每个步骤的证明是否正确时，如何确保每个证明与前一个证明的连贯性，这是一个不确定的问题。

• 公开游戏数据的问题： PopCraft 的游戏数据是公开的，因此隐藏数据没有必要。如果上述验证步骤都能实现的话，下一步需要考虑在合约端保存游戏数据。然而，问题在于，ZKP 证明的性质无法解出具体的游戏数据，此时也不可直接相信前端传到合约的游戏结果数据，这意味着合约无法直接存储这些数据。

• Token 销毁问题： 当游戏涉及到 Token 的消耗时，例如使用Token消除物质时，要销毁对应的Token，如何处理这一步ZKP 生成和验证又是一个问题。

  • 一个可能的思路是，这一步继续按照之前的流程生成 ZKP，验证消耗的 Token 数量并最终发给合约。然而，由于 ZKP 证明无法获取具体数据，合约端无法判断应销毁的 Token 数量。此外，假设玩家拥有 3 个 Token A，却尝试在游戏中消耗 4 个，这种错误可能会在游戏结束时才被发现，而不是在用户操作的最初阶段就得到提示。

  • 另一个可能是，在使用Token消除时，这一步直接与合约交互去销毁，然后更新Token余额，生成的证明只负责保存此时游戏操作和状态的证明。那么此时在销毁成功之后这一步还需要像前面操作一样继续生成证明，如果不生成，那么在销毁Token操作的上一步生成的证明与下一次生成的中间多了一次与合约直接交互销毁的步骤，那么证明中的游戏的状态就会冲突，这样到最后证明是否还会有效也是个疑点。

• ZKP 的数据隐藏问题： PopCraft 这种公开游戏数据的场景来说，数据的隐藏，这一步是多余的，并且增加了数据获取的难度以及实现的不确定性。PopCraft只需要确保游戏过程和结果无作弊，并不需要隐匿具体数据。

结论

在 PopCraft 这样的游戏中，数据是公开的，因此隐藏信息并不必要。为了优化游戏的用户体验，提升响应速度，可以考虑将游戏过程不上链，仅将最终结果上链。关键在于找到一种方法，确保从游戏的第一步到最后一步都没有作弊可能，最后将正确的结果上链验证即可，如果进行了隐藏反倒是增加了更多的难度。其次就是确保游戏过程不作弊，使用ZKP能确保单个的操作得到证明，但是为了加速又不会生成一段证明就提交一次交易，所以从游戏第一步到结束整个过程又如何保证。

https://mud.pixelaw.xyz/

• PixeLAW Core

• paint、snake、2048、15puzzle、pop star

MUD的优点

在开发这些游戏中体验到的MUD的优点（以下仅对我们所使用到的方面进行评价，可能并不全面）：

• 数据处理和同步的便利性
  在构建全链游戏时，智能合约的编写只是其中的一部分。然而，处理前端数据获取和页面渲染等任务却并非易事。传统的方法中，数据结构由合约定义，并存储在链上，而前端则需要通过RPC获取并处理这些数据，这既效率低下又复杂。然而，MUD框架提供了大量开箱即用的功能，利用标准化存储协议构建了熟悉的数据模型。这样它提供了一个索引器，使得前端程序可以轻松地获取链上数据并保持与链上数据的同步。这使得开发变得更加便捷和高效。

• 减少开发成本和学习曲线
  另一个MUD框架的优点在于，如果不使用它，构建全链游戏将会面临巨大的挑战。以 pixeLAW 为例，从零开始构建前端、后端以及二者之间的交互，还需考虑合约中的访问权限控制和数据处理等方面，这将需要大量精力和时间。前端部分，本身对于前端不熟练的我，需要掌握如何构建页面、如何处理数据索引以及如何与智能合约进行交互等技能，这些都是需要付出学习成本的。而使用MUD框架，我只需专注于游戏逻辑功能的开发，极大地减少了开发成本和学习曲线。我可以专心且高效地发挥自己的专长，从而开发出一个完整的全链应用。

• 自由选择前端框架
  最后，MUD框架的另一个优势在于，它并不限制我们在前端开发中使用的框架。根据项目需求和个人偏好，我们可以自由选择MUD所支持的优秀框架，如React或Vue等，来进行页面渲染，从而满足项目的需求。

开发过程遇到的限制

Solidity语言的限制

在开发2048、15puzzle以及pop star等游戏时，我们发现需要使用数组来实现游戏的逻辑。然而，考虑到gas的消耗以及数据的储存，使用MUD框架后，其中的store功能会对数据进行存储，使得我们不再需要在合约中定义storage类型的数组来存放数据。尽管如此，在处理游戏逻辑时，我们仍然需要使用一些临时的数组变量，这些变量通常被定义为memory类型。然而，Solidity语言中，如果一个数组被定义为memory类型，则无法使用push操作向其添加数据。此外，由于游戏逻辑中某个场景无法确定数组的固定长度，因此我们不得不使用动态长度数组，这增加了开发的复杂度。

对于MUD：

在开发pop star过程中，我们计划使用二维数组。当我们获取到用户点击的位置后(x,y)，可以直接从二维数组中获取相应位置的值进行处理。然而，MUD框架的store配置并未包含对二维数组等复杂数据结构的支持，如struct、string[]和bytes[]等。因此，在开发过程中，我们不得不额外处理这些情况。尽管如此，这些限制对我们的开发影响并不是绝对巨大的。MUD框架提供的store功能以及前端的索引器等开箱即用的功能，仍然为我们的开发速度和成本带来了积极的影响。

https://mud.dev/store/data-model#field-types

零知识证明可以让一方 (证明方) 在不透露任何实际信息的情况下向另一方 (验证方) 证明某保密信息或声明是真的。

为什么需要零知识证明？当我们不想披露任何信息，但需要说服其他人相信我们知道的保密信息和提出的声明是真的时候。

目前有两种零知识证明：

1.交互式的 (Interactive)

2.非交互式的 (Non Interactive)：

（非交互式证明是指证明者可以将证明发送给验证者，而无需任何进一步的通信或信息交换。这使得证明系统更加高效和实用。此属性是通过称为Fiat-Shamir 启发式的过程实现的。）

区块链扩容 - Rollups

Rollup 是一种扩容解决方案，在 L1 外执行交易，但在 L1 上发布交易数据。这种工作办法可以让 rollup 对网络进行扩容，但依然受到以太坊共识的安全保护。

将计算转移到链下进行，实际上可以处理更多交易。因为只需要将 rollup 交易的一些数据放进以太坊区块中。

要做到这一点，rollup 交易在另一条链上执行，而这条链甚至可以运行一个 rollup 特定版本的 EVM。

执行完 rollup 上的交易后，下一步是将这些交易打包成一个 batch，然后发布到以太坊主链上。

整个过程基本是执行交易、提取数据、压缩，将其 rollup 到一个个 batch 中然后发到主链上，因而得名 —— ”rollup“。

以太坊怎样得知这些数据是有效的、而不是由恶意份子出于牟利目的而提交的呢🤔？

每个 rollup 都会在 L1 部署一组智能合约，来负责处理存款、取款交易以及验证证明。

证明也是主要区分不同类型 rollups 的因素。

Optimistic rollups 使用欺诈证明。与之相对， ZK rollups 采用有效性证明。

在 ZK rollups 中，发布到 L1 的每个 batch 包含一个叫做 ZK-SNARK 的加密证明。当提交交易 batch 至 L1 之后，L1 上的合约可以快速验证 ZK-SNARK 证明，无效的 batch 会被直接拒绝。

什么是 ZK Rollups？

ZK rollups 是第 2 层扩展解决方案，可在主链上提交汇总版本之前处理计算并在链下处理大量交易。零知识汇总在两个层上提供近乎即时的结算，这与乐观汇总不同。

ZK-rollups 利用其零证明技术，定期向父网络上的关联智能合约提交有效性证明，从而确认第 2 层网络上交易的准确性。对零证明的依赖还减少了共享交易数据量，从而使 ZK rollups 默认以隐私为中心。

除了隐私之外，ZK Rollups 还使用户无需等待数天才能从 Layer-2 解决方案中提取资金。

ZK rollups 的构建更加复杂，需要严重依赖开发人员来维护整个系统。此外，网络结构通常涉及设置复杂且昂贵的硬件来验证交易。根据方法的不同，如果验证排序是集中的，ZK rollups 可能会带来一些相同的审查风险。由于并非所有 ZK rollup 都是相同的，因此需要独立检查这些中心化因素。

zk-SNARK 是如何工作

ZK-SNARK 由三个主要密码功能组成：密钥生成、证明生成和验证。

密钥生成（设置）功能：

密钥生成功能是初始设置阶段的一部分，该阶段生成证明系统运行所需的加密密钥。具体来说，该函数生成一个证明密钥（用于创建证明）和一个验证密钥（用于验证证明）。

例如，C(x, w)是我们需要在不透露细节的情况下验证的逻辑语句。这里，“x”是公共输入，“w”是私有输入（见证人）。设置函数作为该语句的数学表示，将安全参数“λ”作为输入。这用于生成证明密钥“pk”和验证密钥“vk”。

设置(C,λ) → (pk,vk)

证明生成（prove）函数：

该函数由证明者运行来创建加密证明——证明者可以发送给验证者的简洁的零知识证明。证明者采用私有输入**“w”（或证人）、公钥“x”和证明密钥pk来生成证明“prf”** ，证明他们知道该信息而不泄露它。

证明(w,x,pk) → prf

验证（verify）功能：

zk-SNARKs中的验证函数被验证者用来检查证明者提供的密码证明的有效性。验证者使用证明**'prf'、验证密钥'vk'和公共输入'x'来确定证明是否有效。验证（vk，prf，x）→ True（如果有效）或 False（如果无效）。

这满足了零知识证明的所有三个基本属性：

• 完整性：如果初始语句 C(x, w) 是正确的，则始终会生成有效的证明“prf”并被验证者接受。

• 可靠性：如果初始陈述 C(x, w) 不正确，则证明者生成的任何证明“prf”都将被验证者视为无效。

• 零知识：验证者验证证明“prf”，而不了解有关私人输入（见证人）“w”的任何信息。

这是 zk-SNARK 工作原理的基本概述。除此之外，还有三个重要概念为 zk-SNARK 提供支持。它们是：椭圆曲线加密 (ECC)、可信设置和 Fiat-Shamir 启发式

starknet交易生命周期

starknet基于zk-stark，stark与snark类似，不同点在下方指出

Sequencer​

StarkNet 作为一个 Rollups， 没有类似过往我们认识的矿工角色存在，但依旧需要一个角色来 「验证交易」、「决定交易顺序」、「构建区块」，而负责这三者工作内容的人就是 Sequencer。

Sequencer 是一个 off-chain server，工作流程的第一步是接收用户送上来的交易（数笔来自不同用户的不同交易），之后 Sequencer 会决定交易顺序并且构建 L2 的区块。

Sequencer 需要确认交易是被帐户拥有者授权的（由于 StarkNet 使用了原生 AA 的帐户系统，因此这里不一定是单纯确认签名正确，有可能是多签或其他验证逻辑）。接着通过 StarkNet OS 执行一次交易，概念上就像 EVM 一样，接收 input 后执行合约逻辑并产出 output。

Sequencer 执行过交易之后会生产出一个 trace（需要注意这个 trace 不是 function return 而是一个执行过程的见证），并将这些执行内容的过程见证送去给 Prover 让其生产证明。

Prover&Verifier​

Prover 同样也是一个Off-Chain Server，这个角色主要就是接收Sequencer执行完交易产生的trace，并且生产出相对应的STARK proofs，然后交给在L1 上的Verifier Contract 验证，验证通过之后会注册fact供未来的L1 StarkNet Core Contract 进行查询。

L1 Core Contract​

StarkNet L1 Core Contract 储存着 L2 上状态们的证明，大家常常说 Rollups 的安全性是由 Ethereum 这个 L1 保证的就是来自于此。当我们的 trace 经过 Prover 产生 proof 并且在 L1 Verifier Contract 验证之后，就会告诉 L1 Core Contract 这个「状态更新」是正确无误的。

「状态更新」指的是在 StarkNet 执行交易之后会改变状态，而我们要想办法正确地传达给 L1 Core Contract 说 L2 上的状态从 S 更新成 S’ 了。

当 L1 Core Contract 透过 Verifier 知晓了此次的状态更新是合法后，Sequencer 就会在合约中更新 State Root。

换句话说，知道「这次状态更新是合法」的意思是，我们透过 ZKP 证明了链下的运算是真的被正确执行了，而不是瞎掰出来一个随便的交易结果就叫 L1 Core Contract 更新状态。

Starknet 交易生命周期的高级步骤如下：

1. 交易提交：交易被提交到网关之一，充当内存池，并将交易状态标记为RECEIVED。

2. 内存池验证： 内存池对交易进行初步验证。如果交易无效，则不会继续进行。

3. Sequencer验证：Sequencer在执行交易之前对交易进行初步验证，以确保交易仍然有效。如果交易无效，则不会继续进行。

   这种情况下的验证类似于以太坊的签名检查，包括运行帐户的__validate__功能

4. 执行：Sequencer操作按顺序将所有通过初步验证的交易应用到状态。如果交易在执行过程中失败，则会将其包含在状态为 的块中REVERTED。

5. 证明生成和验证： Prover在新块上执行操作系统，计算证明，并将其传输给L1验证器，由L1验证器验证该证明。此时，L1 状态已更新以包含该事务。

ZK-Stark vs ZK-Snark

• 相同点

  • 都实现了将隐私的输入可靠隐藏；

  • 都是基于知识论证，不知道private input的prover生成不了有效的proof；

  • 都可以实现交互式与非交互式的算法，只是取决于randomness是由谁来生成的；

• 不同点

  • zk-stark具有可扩展性，即证明和验证的耗时与原始计算的耗时分别呈拟线性关系（且线性因子为常量）和对数关系，这意味这，如果原始输入的数据集增大1000000倍，zk-stark的证明耗时增加线性倍数的时间，但验证时间仅仅增加21*log1000000 =~ 420倍。证明耗时呈线性关系基本满足所有的ZKP算法，但是验证时间呈对数关系，仅此一家，因此在扩展性上，zk-stark要胜一筹。

    1. 在扩展性方面，STARK 的扩展性更强。证明生成速度具备线性扩展性，验证时间和证明大小具备对数扩展性。但缺点在于生成的证明尺寸更大。但随着证明规模增加，验证成本将会边际递减——这意味证明越大，总成本越低。

  • zk-stark同样具有简洁性，但是是验证简洁性。所谓简洁性，通常是指即使验证程序很大，生成的proof size也不会很大，同时又能很快的完成验证（比native computation快很多）。相比对zk-snark，zk-stark的proof size要大的多，因此在简洁性上，zk-snark要胜一筹。

  • zk-stark有更简单的密码学假设，避免了对椭圆曲线、配对和指数知识假设的需要，纯粹依赖哈希和信息论，因此抗量子攻击。总体来讲 STARK 比 SNARK 更安全。

扩展性详解

Optimistic Rollups 与 ZK Rollups：差异

链上处理的速度是零知识汇总相对于乐观汇总的根本优势。零知识汇总记录到底层区块链的速度比乐观汇总交易更快，因为没有等待期，在此期间交易的合法性可能会受到质疑。

另一方面，零知识汇总所使用的加密有效性证明需要大量的散列能力来计算。因此，乐观汇总解决方案可能对链上活动较少的项目更有帮助。

由于缺乏有效性证明计算，乐观汇总现在更具可扩展性。使用乐观汇总的程序不太可能受到事务大幅激增的影响，而零知识汇总解决方案可能会严重减慢速度。

Optimistic Rollups 和 ZK Rollups 与以太坊网络上的智能合约交互的方式是另一个区别。Optimistic Rollup 可以直接在主区块链上运行智能合约。另一方面，ZK Rollups 无法在主链上执行智能合约。

参考：

https://www.wtf.academy/starknet-basecamp-2023#sequencer

https://blog.thirdweb.com/what-is-a-zk-snark/

https://ethereum.org/en/developers/docs/scaling/zk-rollups/#zk-rollups-and-ethereum

https://zkrollups.io/optimistic-rollups-vs-zk-rollups/

2022年11月ChatGPT发布了3.5版本，迅速成为了炙手可热的大语言模型。短时间内，网络上涌现出了许多基于ChatGPT的想法和应用。

ChatGPT展现了其毋庸置疑的强大能力，同时我们发现它在特定领域的能力依然不够突出。因此我们在思考：能否基于 ChatGPT 训练出一个专精于特定领域大语言模型，使之在该领域的认知更深入、更精准。

以 Metaverse 领域为例，在MetaCat官网中有大量 Metaverse 领域研究的重要文章，因此，我们在寻找一种方法能够将这些文章所传达观点、思维方式赋予类似 ChatGPT 的大语言模型，使之成为一个像 MetaCat 一样具备 Metaverse 领域深度见解的大语言模型，以下是探索过程。

调研：寻找训练出专属数据的“ChatGPT”的方式

我们开始时寻找是否已经有一个模型或者通过对现有模型的训练可以满足需求。通过查阅文档和进行初步的调研，预选了三种方式：

• LlamaIndex（原GPT-Index）

• GPT微调（Fine-tuning）

• BERT微调

LlamaIndex：

简单了解了一下它的作用和工作原理

LlamaIndex是一种面向大规模文本数据集的索引技术，可为结构化和非结构化数据提供索引支持。它将庞大的文本数据集划分为多个小块，并通过索引表快速定位目标文档，以加快检索和处理速度。

在进一步调研之后，我们决定放弃采用LlamaIndex方案。最初我们的期望是让一个模型学习所有的文章，并且在提问时能够对这些知识进行总结和归纳。由于文章的连贯性，这可能需要对整篇文章进行一次性的学习，而LlamaIndex则是通过对内容进行分块索引的方式来工作的，不符合我们的需求。它适用于基于文档内容的对话场景。

接下来，我们将继续探索GPT微调和BERT这两种方式，以找到最适合我们目标的训练方法。

GPT微调：

GPT微调（Fine-tuning）是指在GPT模型的基础上，利用特定的数据集对其进行进一步的训练和调整，以适应特定的任务和应用场景。微调的目标是在已经训练好的模型上进行少量的调整，从而使模型在特定任务上表现更出色。

在微调过程中，我们使用 prompt 和 completion 文本对的格式作为输入数据。例如：

{"prompt":"元宇宙和互联网有什么区别？","completion":" 元宇宙和互联网不同，互联网是一个“二维”的网络世界，而元宇宙则是一个“三维”的虚拟世界。"}

因此，我们需要将文章的内容进行拆分和总结，生成多个文本对，然后使用这些文本对进行微调。值得注意的是，文本对中的信息质量将直接影响微调后模型的质量。

通过利用GPT模型获取每个部分的文本对，并对其进行总结，我们可以基于这些文本对对模型进行微调，这样的微调过程将使模型对特定领域的理解和生成能力得到显著提升。

BERT微调

Google的BERT（Bidirectional Encoder Representations from Transformers），它与GPT都是基于Transformer网络架构。但与GPT不同的是BERT 是一个双向的预训练模型，它通过在大规模无标签数据上进行预训练，学习到句子中各个位置的上下文表示。

BERT主要用于自然语言理解任务，如文本分类、情感分析、命名实体识别等。 它可以理解文本中的语义和关系，并能够找出语句之间的联系

相比之下GPT 则通常用于生成式任务，如文本生成、对话生成等。

这样看下来，通过GPT微调可能会实现我们最初的需求，接着让我们来实现并总结评估一下该过程中遇到的问题。

注：什么是单向预训练模型和双向预训练模型？

单向预训练模型：单向模型只能按照给定的顺序阅读文本，类似于我们在阅读时从左到右的方式。这意味着模型只能看到当前单词之前的上下文信息，而无法预测后面的单词。

双向预训练模型：双向模型可以同时考虑当前单词之前和之后的上下文信息，类似于我们在阅读时可以回头查看前面的内容，然后再继续往后读。这样的模型可以更好地理解整个句子的语义和上下文关系。

实现

https://github.com/themetacat/ChatGPT_Fine_Tuning

注：由于“gpt-3.5-turbo”模型不支持微调，GPT-4 api并未直接开放使用，需要申请加入候补名单所以我们选用GPT-3模型，

1. 首先获取到文章的内容，然后对其结构，内容进行处理

2. 通过 “gpt-3.5-turbo”获得问答对数据

3. 将数据整合上传

4. 根据上传的数据创建微调模型

5. 对模型进行质量评估

我们可以通过GitHub获取到文章content.txt，已经对其进行简单的结构化和内容处理。

（处理原因：原始文章的段落结构可能不代表一个完整的内容段落。例如，第一段可能是提问问题，而第二段则是对问题的解答，这些应该放在同一个段落中。此外，如果文章是由某个组织撰写的，并且内容中出现了大量的"我们"等词语，需要将这些词替换为该组织的名称，以使GPT生成更准确的问题和答案。）

content.txt:
似乎有许多新组织出现，在大型行业参与者的支持下，联合构建元宇宙。然后是 M3，一个由艺术家和开源黑客组成的草根社区，他们也想要参与构建开放元宇宙，并且在同一个章程的指导下已经运营了将近 4 年。

M3代表 Metaverse Makers。我们无法决定第三个 M 是什么，所以发挥你的想象力吧。它是 JanusXR、AnarchyArcade、Webaverse 和 Hyperfy 等创新项目背后思想的家园。自 2019 年以来，我们一直致力于构建一个可互操作和去中心化的元宇宙的共同目标，我们的 GitHub 证明了这一点：github.com/m3-org

......

然后通过“gpt-3.5-turbo”获取对每段内容获取不定量的问答对数据

获取到问答对数据后，我们可以使用官方提供的工具将数据格式转换为JSONL，并将其上传，获取文件的唯一标识符（ID）。

# 由于上传文件的格式要是JSONL的，使用官方 CLI 工具做一下转化，输入以下内容
# openai tools fine_tunes.prepare_data -f qa_pairs.json

# 上传文件
# https://platform.openai.com/docs/api-reference/files/upload
def create_file():
    res = openai.File.create(
      file=open("qa_pairs_prepared.jsonl", "rb"),
      purpose='fine-tune'
    )
    print(res)
    return res

接着，我们可以基于上传的数据文件创建微调模型，以便让模型能够更好地理解和回答特定领域的问题。

def create_fine_tune():
    # file-xxx在上传文件后返回的结果中
    res = openai.FineTune.create(training_file="file-xxx")
    # res = openai.FineTune.retrieve(id="ft-AF1WoRqd3aJAHsqc9NY7iL8F")

    print(res)

最后，我们应对模型进行质量评估。（由于整体需求的性质，每个问题的答案可能是不确定的，类似于语文中的阅读理解。因此，直接进行人工评估可能是最准确的方法。通过评估模型在特定问题集上的回答质量，我们可以进一步优化微调过程，并确保生成的答案的准确性和一致性。）

关键步骤与成本评估

在上述操作中提到，文本对的内容质量会直接影响到微调模型的质量，而处理后的文章内容又会影响到文本对的内容质量。因此，在初期的文章内容和文本对内容处理过程中，我们需要特别注意，因为它们会直接或间接地影响到最终模型的质量。

以此为前提，在初步测试和评估后得到以下问题

1. 在“实现”过程中的第一步是获取所有的文章。这可以通过脚本来实现，但是获取到的文章内容格式可能各不相同，因此需要进行预处理。在此过程中，需要处理的问题是：原始文章中的每个段落不一定代表一个完整的部分。有时，在第n-1段是问题，第n段是答案，或者第n段是问题，第n+1段是答案。因此，这部分预计需要进行人工处理

   ””” 例如： 我们是谁 我们是一群致力于具体化实用“Metaverse”的创客。 我们通过开发产品、内容制作、布道和筹款来做到这一点。 “““

2. 在分段处理完成后，类似于"我们"这样的内容需要明确指出是指文章的作者还是其他人，这样为了获得更准确的文本对，这也需要进行人工处理

3. 处理完内容后，我们可以使用"gpt-3.5-turbo"模型来获取文本对的内容。由于速率限制，每分钟只能调用3次，并且根据token数计费（成本为💲0.002/1k tokens）。对于文章的长度约为1600字，分为15段，获取到了53条文本对，总共花费了💲0.011

4. 对于获取到的文本对的内容，也需要通过人工检查和调整，以使其更加准确。

5. 最后，对于通过微调得到的模型质量，我们需要进行评估。由于每个问题的答案可能不是确定型的，如之前提到的，最好的评估方法是通过人工实际测试。这样可以确保模型在特定领域的问题回答能力的准确性。

6. 在所有的这些步骤处理好了之后，因为文章是频繁更新的，需要更新微调模型，而我在OpenAI文档中并未找到如何对微调模型进行更新操作

总结

在探索“训练一个精通于特定领域的GPT模型”解决方案的过程中，最初，我们希望将所有原始文章的内容输入到一个模型中，以获得专属数据的GPT。然而，我们最终发现这种方法不可行，大多数情况下需要通过微调的方式来实现。因此，我们对微调进行了测试和评估。

经过测试和评估后总结了上述“关键步骤与成本评估”内容，我们也可以看到，需要对所有的文章进行分段、内容处理，并检查获取到的文本对的质量（需要对每篇文章有一定的理解）。此外，我们还需要评估模型的质量（评估者需要具备对文章和MetaVerse领域的一定认知）。所有这些步骤都需要人工进行处理，而且后两步的检查还需要一定的专业能力。综合而言，这会导致成本很高。如果使用一些自动化的方法，很可能会对某些步骤的结果质量产生影响，从而影响微调模型的质量。

目前暂未找到其他方法可以更好的实现我们这个想法，如果读者有更好的期待交流。微调的实现过程所需的内容和代码已经上传到GitHub，供大家参考。如果您在使用过程中发现有任何不清楚或问题，欢迎随时交流。

注：参考资料

OpenAI文档：https://platform.openai.com/docs/introduction LlamaIndex文档：https://gpt-index.readthedocs.io/en/latest/ https://blog.frankzhao.cn/build_gpt_bot_for_doc/

IFTTT和Drippie都是用于自动化任务的工具，实现如果这样(this) 那就那样(that) 的需求。IFTTT已经发展了许多年，而Drippie是新生的产品。他们目标是一致的，但是实现的技术以及面向的对象有所区别，接下来看一看成熟的IFTTT和 新生的Web3 IFTTT——Drippie

IFTTT

介绍

IFTTT (If This Then That) 是一款服务，提供了一种简单的方式来自动化各种日常任务。通过 IFTTT，用户可以将不同的应用程序和服务连接起来，然后创建称为“Applets”(也可以叫做Recipes)的自动化规则，使得在一个应用程序中发生的事件能够自动地触发另一个应用程序的响应。例如，用户可以创建一个Applets：如果他们的Twitter收到消息，那么就把这个消息发送到他们Gmaill。

实现

由于IFTTT集成了许多第三方服务，也会存在大量的Applets，那么对于数据的处理架构就需要非常完善严谨。

数据处理的基础架构：

1. AWS Data Pipeline：AWS Data Pipeline 是一种自动化的 ETL（Extract, Transform, Load）服务，它可以让用户在 AWS 云上轻松地从各种数据源中提取、转换和加载数据。IFTTT使用Data Pipeline来将数据从不同的数据源中提取然后将结果存储在AWS Redshift、AWS RDS等目标数据存储中，供后续的分析和可视化使用。

2. AWS Redshift：Amazon Redshift 是一种高性能的云数据仓库服务，它可以大规模地处理和分析数据。IFTTT使用Redshift来存储和分析用户数据和事件数据。

3. Chartio：Chartio 是一种云 BI（Business Intelligence）工具，它可以连接各种数据源，并提供交互式的数据可视化和报表功能。IFTTT使用Chartio来创建和共享数据报表和仪表板更好地理解其数据。

4. Kafka：Apache Kafka是一种分布式流处理平台，用于处理高速数据流。IFTTT使用Kafka作为事件流处理引擎，以支持实时事件处理和数据分析。

5. AWS S3：Amazon Simple Storage Service（S3）是一种面向对象的存储服务，它可以让用户在云中存储和检索任意数量的数据对象。例如执行的日志、Recipes的输入和输出、触发器数据等。

6. Cranium ETL：Cranium ETL 是一种开源的 ETL 工具，它可以帮助用户从各种数据源中提取、转换和加载数据。IFTTT使用Cranium ETL来自动化数据清理和预处理。

7. Spark：Apache Spark 是一种快速、通用、可扩展的分布式计算引擎，它支持大规模数据处理和机器学习等任务。IFTTT使用Spark来确保IFTTT用户有良好的体验

8. Recipe Worker：Recipe Worker 是一个用于执行 Recipes 的服务，它是整个 IFTTT 系统的核心部分之一。当一个 Recipe 被创建或更新时，IFTTT 的服务器会将该 Recipe 发送到 Recipe Worker，Recipe Worker 会按照指定的触发器和动作，从不同的数据源中获取数据并执行相应的操作。因此，Recipe Worker 是一个高度可扩展的系统。

9. Partner APIs：Partner APIs 是 IFTTT 用于与第三方服务进行集成的接口。通过与其他公司的 API 集成，IFTTT 可以在其平台上创建更多的 Recipes，并提供更多的服务。IFTTT 的合作伙伴可以通过 Partner APIs 来访问 IFTTT 平台，并提供他们自己的触发器和动作，以及其他的功能。

10. Elasticsearch：Elasticsearch是一种分布式搜索和分析引擎，可用于实时搜索、日志分析、安全分析等。IFTTT使用Elasticsearch作为日志分析引擎，以支持日志分析和异常检测。

11. Internal Monitoring Alerting：Internal Monitoring Alerting 是 IFTTT 用于监控其整个系统的服务。这个服务通过定期检查 IFTTT 的各个组件的性能和可用性来确保系统的正常运行。当系统出现问题时，Internal Monitoring Alerting 会向 IFTTT 的运维人员发送警报，以便他们可以采取相应的措施来解决问题。

在IFTTT有三种数据来源，对于理解用户的行为和Channels的效率至关重要。

第一，在 AWS RDS 有一个 MySQL 集群，用来维护应用的基本内容的当前状态，比如用户、Channels和Recipes，包括他们的关系。IFTTT.com 和移动应用靠Rails应用(支持 IFTTT 网站和移动应用的后端程序)支撑。获得数据并导入到S3，然后用AWS Data Pipline导入到Redshift。

接下来，像用户与 IFTTT 产品的交互数据，从Rails应用里收集事件数据到Kafka集群。

最后，为了帮助监控数以千计的合作伙伴 API 的行为，IFTTT收集在运行 Recipes 时 workers 产生的 API 请求的信息，包括响应时间和HTTP状态码，都导入到Kafka集群。

使用Kafka做数据传输层，实现数据生产者和消费者之间的解耦。这种架构中，Kafka在系统中作为生产者和消费者之间的一种抽象层，而不是数据直接推向消费者。生产者将数据推送到Kafka，消费者从Kafka中读数据。这使得添加新数据消费者更松散。

Kafka是一种基于日志的事件流，它可以跟踪消费者在事件流中的位置，因此消费者可以实时或批量地处理数据，并且可以重新处理之前已经消费过的数据。这为数据处理提供了更大的灵活性和可靠性。

一旦数据进入Kafka中，就可以应用于多种不同的场景。例如：批量数据的消费者可以将数据的副本分批存储到S3中，以便后续使用。另一方面，实时数据的消费者则可以将数据传输到Elasticsearch集群中，以实现实时的数据查询和分析。

用Cranium（内部ETL平台）将S3中数据变换和归一化后导入到AWS Redshift。通过Cranium能够用SQL和Ruby编写ETL任务，它定义了这些任务之间的依赖和安排他们执行。Cranium支持数据可视化报告（利用Ruby和D3），但是大多数数据可视化是用Chartio。

无论是工程中还是业务中甚至是社区中人们都可以利用这些数据来解决问题，发现新的点。

并且采用一些先进的机器学习技术来确保IFTTT用户有良好的体验。对于Recipe的推荐和滥用检测，IFTTT用在EC2上的运行Apache Spark，用S3作数据存储。

API 事件存储在 Elasticsearch 中，来进行实时监控和报警。并使用Kibana来可视化worker进程的实时性能和合作伙伴的API性能。

IFTTT的合作伙伴访问Developer Channel（当他们的API有问题时触发这个Channel）。可以用Developer Channel 创建Recipes，可选择不同的方式（SMS，Email，Slack等）来通知合作伙伴们。

在开发者dashboard，合作伙伴可以访问实时日志和可视化他们的Channel健康状况。 用Elasticsearch来实现比较好。此外，提供给开发者强大的分析能力帮开发者们了解谁在使用他们的Channel以及如何使用的。

工作流程举例：

1. 用户在IFTTT官网上创建一个Applet，其中包括两个触发器（Trigger）：一个是Twitter消息触发器，另一个是Gmail消息触发器。用户还需要授权IFTTT访问他们的Twitter和Gmail帐户。

2. 用户保存Applet后，IFTTT将应用程序定义存储在其数据库中。在这个过程中，IFTTT使用AWS RDS来存储应用程序定义，并使用AWS Data Pipeline将数据从RDS导出到AWS Redshift中，以供后续分析和处理。

3. 用户的Twitter账户是作为触发器来监视消息的。当IFTTT检测到Twitter帐户收到了一条新的消息时，它将消息推送到Kafka，Kafka是IFTTT数据传输层中的一部分。在这个过程中，IFTTT使用Kafka来实现数据生产者和消费者之间的解耦，以及添加新的数据消费者的松散耦合性。

4. 一旦消息推送到Kafka，Recipe Worker会从Kafka中读取数据并将它们分配给相应的Applet执行。在这个过程中，IFTTT使用Recipe Worker来执行与应用程序相关的逻辑，例如连接Twitter和Gmail，以及将Twitter消息发送到Gmail。

5. 在执行过程中，IFTTT还将使用Chartio来监视和分析系统的性能和运行状况。此外，IFTTT还将使用内部监控和告警系统，例如AWS CloudWatch和PagerDuty，来监视系统的状态并通知运营人员进行干预。

6. 最后，IFTTT将使用Elasticsearch将处理后的消息存储到集群中，以供后续查询和分析。

以上是一个大致的流程，不同的场景可能有些许的不同，但是整体的架构和流程是相似的。（Drippie同理）

trigger(this)数据的获取

1. 在第三方支持Webhook情况时，例如Twitter：一旦用户创建了Applet，IFTTT会向Twitter API注册一个webhook，以便Twitter在有新消息时能够将消息发送到IFTTT。IFTTT会持续监听Twitter API的推送，一旦有新消息，IFTTT就会将其封装成一个事件，并触发相应的Applet执行。

2. 如果第三方不支持 Webhook，IFTTT 可能会使用轮询的方式来获取数据并触发 Applet。IFTTT 会使用后台服务，如 Recipe Worker，定期执行定时器任务。当定时器任务触发时，IFTTT 会向第三方服务发送 API 请求，以获取最新的数据。如果数据符合 Applet 的触发条件，IFTTT 将触发相应的操作。

需要注意的是，轮询方式比 Webhook 方式要消耗更多的资源和时间，因为每次轮询都需要向第三方服务发送 API 请求，这可能会导致 API 请求的频率过高，从而影响性能。因此，IFTTT 一般会优先选择支持 Webhook 的第三方服务。

那对于IFTTT每天会有大量的Applet去监听执行，所以当有大量的任务需要定时轮询时，每个任务都单独使用一个定时器是不可行的，因为系统资源会被过度占用，导致性能下降。因此，IFTTT 使用了一种基于时间轮的调度算法来处理大规模的定时轮询任务。时间轮是一种定时轮询的数据结构，可以将定时器按照过期时间分组，并在每个时间间隔内执行一组定时器。因此，IFTTT将所有需要定时轮询的任务按照一定的规则分组，然后根据任务的过期时间将它们添加到相应的时间轮上。这样，当时间轮到达特定的时间间隔时，IFTTT 就可以一次性地执行整个时间轮中的所有任务，而不是一个个单独执行。这样，IFTTT 可以轻松地管理大量的Applet，而不会过度占用系统资源。

Drippie

介绍

Drippie是 Optimism 的机制，用于（主要）解决自动化链上活动带来的问题。Drippie 基本上是If This Then That (IFTTT)的以太坊原生版本。与 IFTTT 一样，Drippie 可以（在 Solidity 中）进行编程以对各种链上数据做出反应，并针对该数据执行各种不同的操作。Drippie 系统中的每组检查/操作都称为“drip”。简而言之，它看起来像这样：

什么使Drippie来自动化执行？

Drippie 是一个允许在特定条件下执行操作的系统。但是，仍然需要一些服务来在满足必要条件时触发这些操作。

Drippie集成了Gelato、Chainlink Keepers或OpenZeppelin Defender AutoTasks等服务，可以定时调用指定drip。

Gelato是一个基于以太坊的去中心化自动化服务，它可以让智能合约开发者轻松设置条件触发器，例如当以太币价格下降到一定程度时自动执行卖出操作，以实现自动化交易。Gelato 还提供了一些内置条件触发器，例如定时器、价格预警等，以满足各种自动化交易的需求。

Chainlink Keepers是Chainlink的智能合约自动化服务，它可以执行链外任务并触发智能合约。这使得链上智能合约可以响应链外事件，从而可以实现更复杂的智能合约自动化任务。

OpenZeppelin Defender AutoTasks是OpenZeppelin的智能合约自动化服务，它可以通过与 Etherscan 和其他链上服务的集成来管理和监视智能合约。AutoTasks提供了一系列内置任务类型和条件触发器，例如执行函数调用、检查合约状态、触发警报等，以实现更可靠的智能合约自动化任务。

架构图

• 检查事件的合约（判断是否到达可执行的状态）

• 执行事件合约（当检查事件判断到达可执行的状态后，调用该执行合约执行相对应的操作）

• 配置文件 （*.ts 文件）（包括每次执行drip间隔时间，触发事件，检查事件的合约(check.sol)，执行事件合约(target.sol)等）

• 获取每个drip的配置，调用Drippie.sol合约中创建相对应的drip （*.ts）

• Drippie.sol （生成drip，更新drip状态，查看drip是否到了执行的间隔时间以及drip的状态是否可执行等，官方已部署）

• 定时触发检查执行的应用（Gelato、keepers、AutoTasks、etc.）

整体流程：

1. 以 this为查询账户余额，如果低于某个值 和 that为向该账户中转入某个值的金额 进行举例

2. 首先编写并部署 check.sol和target.sol，check.sol负责对传入的账户检查余额，比如如果余额低于了某个值返回True。target.sol负责去向指定目标账户转账。（check.sol和target.sol都需要根据自己的需求去定）

3. 之后填写配置文件中的相对应的参数（可以添加多个drip的配置）： 每两次执行检查的间隔时间、检查是否达到可执行条件的合约(check.sol)、传入该合约function中用到的相对应的参数（比如要检查余额的账户等）、执行事件合约（target.sol）等等参数

4. 通过 Install-drippie-config-multisig.ts 文件读取上方配置文件中的每个drip的配置，然后调用drippie.sol的create function创建相对应的drip，此时合约会判断是否存在该drip、记录该drip相对应地状态以用于在执行时判断是否可执行、创建drip等操作，然后会把这些信息创建一个bundle文件。最后再提交给Gelato以供定时调用合约执行。

5. 执行drip：Gelato会根据配置去定时调用drippie.sol中的drip function以执行刚刚创建的drip，执行期间首先会调用executable function去检查是否达到了可执行的状态（检查drip相对应地状态）、判断与上次执行的间隔日期是否达到了设置的要求、判断是否达到了可执行条件(check.sol去检查账户的余额是否低于了设定的值)等等验证，如果最后check.sol验证也没问题，执行去调用target.sol执行转账等操作。

对比总结

从适用场景来看：IFTTT主要应用于互联网常用服务的集成，例如邮件、社交网络、智能家居等。适用于普通用户和企业用户。而Drippie面向Web3生态，适用于去中心化的应用和智能合约，主要应用于以太坊智能合约中的定时任务。

从大体上对模块进行分析

IFTTT主要使用API和Webhooks技术实现服务的集成和触发，同时也支持自定义应用。

Drippie主要使用以太坊智能合约和Gelato来实现定时任务的自动化。

而从灵活性的角度出发：IFTTT提供的触发器和动作是固定的，不能自定义，用户只能选择现有的触发器和动作进行组合。因此，IFTTT的可编程性相对较低。Drippie则通过智能合约实现交易策略的编程和自动化执行，用户可以自定义各种条件和动作，具有更高的可编程性。

从整体的完善角度来看：由于IFTTT已经发展了很长时间，对于用户的使用体验上做得更完善，使用起来也比较简单，集成的服务也比较多，对于存在的Applets有一个很好的监控方案和错误处理机制。而Drippie由于比较新，在这方面还不如IFTTT。

总的来说，IFTTT和Drippie都是自动化任务的工具，但面向的应用场景和技术架构有所不同。IFTTT主要应用于传统互联网领域，通过API和Webhooks将用户不同应用的操作联系起来；Drippie则面向Web3领域，利用智能合约实现自动化交易策略，具有更高的可编程性和安全性，但需要一定的技术门槛。

社交是生活中必不可少且非常重要的一部分，现在存在很多社交应用，但是都存在一些严重的问题：用户的数据并不真正的属于用户、各个平台对于用户的数据并不互通、用户辛苦的创作与平台的收益对比屈指可数。因此出现了一些去中心化的社交协议，旨在通过区块链和去中心化技术解决这些问题

Lens Protocol

Lens Protocol是基于区块链技术的去中心化社交协议，几乎涉及的所有操作都要与智能合约交互。它是由去中心化借贷平台Aave 的创始人Stani Kulechov 于2022年2月8日推出的项目，在发展与用户数量方面是同类项目中最好最多的

Lens Protocol旨在使创作者能够拥有自己与社区之间的联系，形成一个完全可组合的、用户拥有的社交图谱

该协议的设计核心是模块化概念，具有高度灵活性和可扩展性的特征。

概念

• Profile NFT: 储存用户的各种信息(名字、简介、头像等)

• Publication：Lens Protocol的核心。Publication主要分为三种类型：posts、comment和mirror。posts是创作者发布的文章等，其他人可以对其进行评论(comment)和转发(mirror)

• Mirror：对其他用户发的文章等进行转发，以自己的身份重新发布该文章的内容，但是文章的创作者不会改变。本质上是Publication，只是增加了一些额外的检查和一些次要功能

• Comment：用户的评论，每一条评论都会存在于用户的信息当中，所以永远数据用户。本质上也是Publication

• Follow： 不同于 Web2 社交应用中的关注。当用户关注其他Profile NFT时，他们会获得 Follow NFT。此外用户还可以设置被关注时需要支付Matic进行关注

• Collect：对其他Publication进行收藏。创作者可以通过他们的内容获利，允许他们的追随者购买该内容。会铸造Collect NFT

整体流程：

实现流程

• 可以使用自己的以太坊钱包地址登录 → 创建一个Profile NFT → 调用部署在Polygon上的合约 → 合约代码对用户是否在白名单中进行验证等操作 → 获得Profile NFT。

• 发布文章/评论/转发（本质上是Publication，会在此基础上增加一些额外的检查和次要的功能） → 调用合约中的相对应的function → 发布

• 关注某用户/收藏文章 → 调用合约 → Mint NFT →关注/收藏成功

概述

Lens Protocol是基于NFT技术的身份验证协议，它的主要目标是建立一个去中心化的身份验证系统，让用户的身份信息归属于自己，而不是掌握在中心化机构手中。通过在Polygon链上部署合约，用户可以创建自己的Profile NFT，以此来代表自己的身份信息

相较于传统的中心化身份验证系统，Lens Protocol具有更好的数据自主权和隐私保护，因为用户拥有自己的Profile NFT，可以自由地在多个应用间进行身份验证和数据共享

但是，使用Lens Protocol也需要注意一些限制。由于所有的操作都需要与合约交互并上链，这会带来一定的性能问题，同时也会需要支付一定的Gas费用。此外，Lens Protocol并不会介入内容审核，而是由各个应用自己制定相应的策略

RSS3

RSS3项目由团队 Natural Selection Labs 开发

RSS3 源自 RSS 的精华，是一种以提要和搜索为核心要素的 Web3 信息传播协议。它定义了信息呈现和通信的格式，通过这种设计优雅、用户友好的内容格式，客户端可以轻松访问统一格式的各种内容源，而无需大量的兼容性逻辑

其认为创建、传播和分发信息的权利不应掌握在中央集权手中，这是网络生活的基本权利

架构

• 服务节点SN -- Serving Node：储存RSS3 File并且负责相应文件相关请求，一个节点可以服务的文件数量被DAO限制

• 服务节点组 -- Subgroup：由多个SN组成

• 全局索引器 -- GIS：协调Subgroup、路由客户端请求并维护网路的功能。DAO设置了激励机制

• 中继节点 -- RN：GI的一部分，协助路由

全局索引器（GIs）与服务节点组（Subgroup）将由网络选举产生，全局索引器（GIs）与服务节点组（Subgroup）选举、网络节点数量上限、节点作恶处罚、节点激励机制、网络模组升级和网络金库管理等事物都将由RSS3代币持有人投票决定

无处不在的Link是开放信息系统的基础。RSS3协议支持RSS3对象之间的自定义类型通用链接。主要RSS3对象包括：

• Instance，基于加密账号的集合

• Aseet，数字生成的交换媒介

• Item，网络上生成的内容

流程

每个RSS3 Files代表一个用户，储存用户的个人信息等数据

用户使用该身份订阅其他应用获取自己发布的内容。比如Twitter，在订阅后可以看到自己在集成该协议的应用上看到自己曾在Twitter上发布过的文章等内容

然后该RSS3 file会随机储存在各个SN中，然后再由GIs协调Subgroup、路由客户端

Activity Feed

在RSS3文件中，Activity包含：

• 所有活动 根据实例验证的帐户索引

• 所有项目 由实例或网络生成

• 所有通用链接 在RSS3网络上生成

奖励机制

• 阶段1：系统奖励 一开始，网络会受到系统的奖励以鼓励产品/协议/网络/系统的采用。 系统报酬逐渐降低，与网络的使用成反比

• 阶段2：混合奖励 随着网络使用率的增加，广告、增值服务和其他相关经济活动等活动有望产生利润。 收益将以网络奖励的形式分配，这也抵消了系统奖励

• 阶段3：自我奖励 所有奖励现在都完全转化为网络生成的奖励，系统将不再激励网络。 激励将分发给网络参与者，包括节点主机、开发者、内容创作者、特别贡献者和DAO

概述

RSS3协议的优点之一是其去中心化的特点，这使得用户的数据可以更加安全地存储和管理，而且用户可以更好地控制自己的数据。此外，RSS3协议的格式化设计使得客户端可以更轻松地访问和处理各种内容源，提高了用户体验和数据利用率

在应用方面，RSS3协议可以用于社交媒体、新闻聚合、博客订阅等场景。通过订阅RSS3文件，用户可以获取自己感兴趣的信息，而且无需访问原始网站，可以节省时间和网络流量。此外，由于RSS3协议的开放性和可扩展性，未来还可以有更多的应用场景和创新

这也是与Lens Protocol、CyberConnect不同的点，使用该协议可以通过对其他应用网站进行订阅获取内容，RSS无需访问源站即可获取信息，并且数据及时性强，阅读效率高。且RSS内容不显示源站广告。例如：可以进行对Twitter的订阅，此时会获取到自己曾经发布过的推文，然后再对一些Web3的应用进行订阅，就可以在个人信息中看到在订阅到的应用中自己曾经发布过的所有内容。而像Lens Protocol则是先获取Profile NFT，以该身份去发布内容

CyberConnect

CyberConnect 是一种去中心化的社交图谱协议

Cyber​​Connect 建立在BNB Chain之上，使用户能够真正拥有自己在社交网络中的社交身份、内容和关系，并为开发人员提供丰富的工具集来构建具有有意义的社交体验的应用程序

概念

• ccProfile NFT：ccProfile 将每个用户的个人资料表示为一个 NFT。它是想要发行其定制 EssenceNFT 或 SubscribeNFT 的用户的先决条件，开发人员能够使用 Cyber​​Connect 将所有链上凭证/资产映射到 ccProfile。无论是 NFT、SBT、Twitter 用户名还是 DID

  开发人员能够使用 Cyber​​Connect 将所有链上凭证/资产映射到 ccProfile。无论是 NFT、SBT、Twitter 用户名还是 DID，都将它们映射到一个整体身份：ccProfile。

• SubscribeNFT：表示地址和 ccProfile 之间的单向关系。SubscribeNFT 可以配置 pay-to-follow（付费订阅者）、hold-to-follow（代币门控社区）等规则。可用于表示任意社交关系；包括关注、订阅创作者、朋友关系、属于某个组织以及参与活动和社区

• EssenceNFT：EssenceNFT 是一种通用的 NFT，个人 ccProfile 持有者可以发行它来代表任何内容（例如社交媒体帖子、视频、博客出版物）。每个 EssenceNFT 都可以配置 pay-to-mint（众筹）、hold-to-mint（社区参与者）等规则。它也可以配置为可交易的 NFT 或不可转让的灵魂绑定令牌（SBT）以代表给定的角色，例如投资者、赞助人、团队成员、社区参与者等

• 可扩展存储模块 (SSM) ：由于智能合约会遇到可扩展性问题和高 gas 成本问题。对于可能达到数十亿的社交内容和连接数据，以分散、自主和可扩展的方式存储它们的方法非常重要。Cyber​​Connect 提供可扩展存储模块 (SSM) 以在去中心化存储 (Arweave) 中写入社交数据，并保证数据主权（数据不能伪造）、完整性（数据不能以未经授权的方式修改）和可用性（数据不能被篡改）

CyberConnect 还有中间件选项，支持两种配置：Collect和Subscribe

可以通过中间件来对这两种类型操作进行限制要求，比如：想要进行Subscribe需要收费，或者在Collect时只有订阅了该创作者的用户才可以进行操作

概述

CyberConnect与Lens Protocol有些相似，都使用NFT来代表用户身份，让用户拥有更多的控制权。但是它们之间还存在一些差异。相比于Lens Protocol需要支付gas费，CyberConnect使用可扩展存储模块 (SSM)和去中心化存储 (Arweave) 来处理Post和评论等数据，从而减少了用户的成本和复杂度

这样的设计可以让用户更好地接受，因为他们可以更方便地使用CyberConnect，而不用为了每一个操作都支付gas费用。同时，这也体现了CyberConnect的可扩展性，因为它可以轻松处理更多的数据，而不会受到gas限制的影响

总之，这个不同是CyberConnect与其他社交协议的一大优势，它能够让用户更轻松地管理和掌控自己的数据，提供更好的用户体验

总结

这三种社交协议的设计理念都是为了让用户对自己的数据拥有更多的自主权，并且摆脱数据滥用和数据垄断等问题，这是当前web2社交产品所面临的问题。这些简单、开放、免费且没有数据垄断问题的社交协议正是用户所需要的

Lens Protocol是一种基于NFT的身份验证协议，旨在为用户提供可信的数字身份，方便跨应用使用。它的主要目标是建立一个去中心化的身份验证系统，让用户的身份信息归属于自己，而不是掌握在中心化机构手中

RSS3协议则是一种基于Web3的信息传播协议，用户可以方便地订阅多个应用的内容，并通过去中心化的方式管理和掌控自己的数据。RSS3旨在解决当前社交媒体存在的数据分散和流动性差的问题，提高用户对自己数据的管理和控制能力

而CyberConnect则类似于Lens Protocol，它的主要目标也是解决社交网络中的隐私问题，使用户能够掌握自己的数据。但体验上来讲用户在发布内容时并不会像Lens Protocol需要支付Gas费

总的来说，这些协议虽然在理论上看起来很有前途，但在实践中仍然需要面临各种挑战，比如用户体验、可扩展性、开发人员的使用难度等问题。然而，这些协议的发展前景仍然值得期待，他们的核心目标都是值得注意的，并且也许在未来的社交网络中发挥重要作用

本文将分析和讲解Mastodon和Nostr这两个社交媒体平台，重点关注它们的产品应用和技术层面，以了解它们如何实现去中心化社交，并探讨它们在这方面的优势。我们将深入了解它们的架构设计和实现思路，并比较它们在用户体验、隐私保护、安全性等方面的差异。通过本文的分析和总结，读者将更好地了解这两个平台，以及它们在去中心化社交方面的贡献和发展。

Mastodon

Mastodon(长毛象)成立于2016年，是由Eugen Rochko创建的一个开源的微博客(microblog)平台，旨在为用户提供去中心化、隐私保护的社交体验。

首先对涉及到的一些名词进行简单解释：

• 联邦(federation)：联邦是去中心化的一种形式。在联邦中，不是所有人共同使用一个中心服务，而是使用多个不限人数的服务器。

• ActivityPub：Mastodon使用一种标准化的、开放的协议来实现站点之间的互动，这种协议叫做ActivityPub。任何通过ActivityPub实现互联的软件都可以与Mastodon无缝通信，就像Mastodon站点之间的通信一样。

• 实例(instance)：每个人都可以在自己服务器上配置运行Mastodon服务，这个服务器可以被叫做营运站点，每个营运站点被称为实例(instance)。

Mastodon在使用体验上非常类似于Twitter，但它是去中化的，这是Mastodon与Twitter，YouTube等社交媒体最大的不同之处。

Mastodon社区是由无数实例组成的。Mastodon的用户数据存储在不同的实例中，每个实例都是独立的，用户可以在不同的实例之间无缝连接，这种分散的数据存储方式可以更好地保护用户的隐私。此外，每个Mastodon实例都有自己的隐私政策和使用条款，用户可以自由选择注册哪个实例，选择自己信任的实例来保护自己的数据隐私。 每个人都可以搭建实例，每个实例可以有它自己的主题，比如卡通，休闲，动物，编程等等，也可以没有任何特定主题。

Mastodon采用的是ActivityPub协议来实现站点之间的互动。与其他常用的社交媒体不同的是，Mastodon的用户不仅可以互相关注、分享内容、评论和转发。而且可以与来自其他通过ActivityPub实现联合的软件的用户进行互动，这样就扩大了用户的社交范围，促进了社交网络之间的互联互通。 这些软件和社交网络之间的互联互通构成了联邦(federation)的网络结构，而这些软件被统称为联邦宇宙(Fediverse)。包括但不限于以下应用：

• Pleroma，一个模块化的微博引擎

• Pixelfed，联合图像共享平台，可让您共享和使用媒体帖子

• Misskey，其中包括微博和可定制的仪表板

• PeerTube，可让您将视频上传到频道

• Plume，它可以让你发表长篇文章

ActivityPub协议中规定了一些可选的元数据，实例可以选择只存储部分元数据，以减少存储空间的占用和网络带宽的消耗。例如，实例可以选择只存储文章的标题、作者和摘要。 当用户A发布到了实例A上，实例A会储存该文章的所有数据，用户B在实例B关注了用户A，此时实例B也会储存该文章的所有数据，用户C在实例C中未关注用户A，那么实例C储存的就是该文章的部分元数据。

Mastodon还有一个值得一提的特点，就是它没有广告。相较于其他社交网络，Mastodon没有中心化的广告商，也没有实例可以通过插入广告来获利。这是因为Mastodon的分布式结构和ActivityPub协议的应用，使得每个实例都是独立运营的，不会依赖于广告来维持运营。而且，由于Mastodon的用户分散在不同的实例中，广告的效果也很难被量化和追踪，因此广告在Mastodon上不具备实际的商业价值。

由于Mastodon免费开源以及不存在广告，所以只能通过捐款的方式支持开发团队和实例服务器的运营成本。

Nostr

Nostr 是由fiatjaf开发，于2020年启动的一种简单、开放的社交协议，支持全球、去中心化和抗审查的社交媒体。

运行原理：

• 有两个主要组件：客户端和中继。每个用户运行一个客户端。任何人都可以运行中继。

• 每个用户都由公钥标识。每个帖子都有签名。每个客户端都会验证这些签名。（客户端需要用户的私钥对该用户发布的帖子签名。签名可以确保该帖子的创建者）

• 客户端从他们选择的中继获取数据以及将数据发布到他们选择的中继。中继之间不互相通信，仅与客户端通信，使用 WebSocket + json 协议。

• 要查看某人的帖子，用户只需指示他们的客户端查询它知道的中继以获取来自该公钥的帖子。

由于WebSocket协议提供了更好的实时性和可靠性，这对于一个社交媒体平台来说非常重要。在Https中，每个请求都要进行TLS握手，这会导致一定的延迟。而一旦建立了WebSocket连接，后续的消息传输将会更快，因为WebSocket连接是始终打开的，没有额外的TLS握手。此外，WebSocket还支持双向通信，这意味着服务器可以主动向客户端推送数据，这是Https所不具备的。因此，选择使用WebSocket，以提供更好的实时性和可靠性。

使用：

• 每个 Nostr 帐户都基于公钥/私钥对，而非电子邮件和密码。公钥相当于是用户名，私钥相当于密码。与密码不同的是，私钥丢失后无法重置。公钥通常以前缀为 npub1 的字符串表示，私钥以前缀 nsec1 表示。

• 每个人都运行一个客户端。 它可以是本机客户端、Web 客户端等，连接一个或者多个中继。

• 要发布某些内容，例如一篇文章，用私钥对其签名并将其发送到多个中继（由其他人或您自己托管的服务器）。

• 要从其他人那里获得更新，您可以询问多个中继是否知道这些其他人。 任何人都可以运行中继。 继电器非常简单。 除了接受某些人的帖子并转发给其他人之外，它什么都不做。不必信任中继， 签名在客户端进行验证。

在Nostr中，Event是一种用于描述用户在社交网络中进行的行为（如发布消息、关注某人等）的数据类型。在客户端发送Event时，它会先进行签名，然后才会被发送到中继节点。 比如用户A发布一篇文章到中继A、B：客户端A使用用户A的私钥对其进行签名，获取文章时使用用户A的公钥对其签名进行验证。如果中继A的拥有者对该文章进行更改，则验证也就不通过，客户端也就不会对其进行展示，只会展示从中继B获取的正确的文章内容。

优势：

• Nostr协议是基于分布式的网络模型，这意味着数据被存储在许多不同的节点上，而不是集中在单个服务器上。这种去中心化的架构使得Nostr更加抗审查。

• Nostr协议为用户提供了更好的隐私保护。客户端在用户发布文章后对其进行签名，获取文章时会对该文章签名认证，以确认文章是否被更改。

• Nostr协议的中继也可以向用户收取费用以在此中继发布，这也为中继提供了一种经济支持。

由于Nostr是去中心化的，和中心化的服务（如Twitter）不同，所以Nostr的发展方向取决于所有人的意愿。为了让用户更好地参与协议的改进和发展，Nostr引入了NIP（Nostr Improvement Proposals）这一标准化流程，用于提出和讨论对Nostr协议的改进建议。任何人都可以通过提交NIP来对Nostr协议进行改进和发展，这有助于保证协议的发展方向更加民主和开放。NIP的目的是让改进流程更加透明、高效和安全，保证所有人都可以提出协议改进的建议，并且让改进的流程变得更加规范化和公开。

核心特点对比：

总结：

Mastodon和Nostr都是为了实现去中心化社交

从用户数据隐私层面看，我认为Nostr更占优一点，由于Mastodon的账户模式不同于Nostr的公私钥对，用户登录需要服务器来认证，这本身是一个中心化行为，而且用户需要信任使用的实例，而Nostr的客户端使用用户私钥对其的数据进行签名以验证数据的完整性。

从更宏观的角度来看，由于Mastodon的实例使用ActivityPub协议，它可以实现各个软件中的互联互通（前提这些软件应用也集成了ActivityPub协议，理论上如果Twitter以及Youtube实现了该协议也可以与Mastodon实例通信），如果集成该协议的应用越来越多，联邦宇宙的规模和潜力就越大，那么也就会更有优势和发展空间。试想一下，我在Twitter中看到了Youtube中的视频以及Instagram中的内容，并且还可以点赞评论和转发。

对于 MetaMask、Imtoken 等（EOA）钱包来说，确实存在一些繁琐的流程。例如，用户需要学习如何安全地保存助记词、如何将账户导入到新设备等。然而，可以使用托管服务来代替这些流程，从而使用户更轻松地接入 Web3。

下文涉及到的名词：

• DKIM（DomainKeys Identified Mail）

• Threshold Signature Scheme（TSS)

• Multi-Party Computation（MPC）

• Shamir's secret sharing (SSS）（Shamir 秘密共享)

• Threshold Signature Scheme（TSS）

Web3Auth（用于 Web3 wallets和应用程序的可插入身份验证基础架构）

使用Web3Auth 可以让用户通过 Google、Twitter、GitHub 等在各种应用中进行注册登录。用户也可以通过发送电子邮件的方式，进行无密码设置的注册。

Web3Auth使用SSS，通过将密钥（这个密钥不是特定于任何一个账户地址的私钥。Web3Auth使用这个密钥来生成和管理不同的账户。下同）分成几个部分(share threshold)（下文中shareA/B/C），登录时需要ABC中的两个share，这样即使服务方保存了其中一个Share也无权访问账户，进一步降低中心化的风险以及当用户丢失其中一个share可以通过另外两个重构密钥，增加了安全性。

实现原理：

用户第一次使用他们的社交账户（Gmail/Twitter）登录时，会为用户生成三个Shares：ShareA、ShareB 和 ShareC，然后分开存储

1. ShareA 存储在用户的设备上：实现是特定于设备和系统的。例如，在移动设备上，共享可以存储在通过生物识别技术保护的设备存储中。

2. ShareB 由节点运营商的登录服务管理：该共享在节点网络中进一步拆分，并通过传统的身份验证流程检索。

3. ShareC 是一个恢复共享：由用户保留的额外共享，可能保留在单独的设备上，下载或基于具有足够熵的用户输入（例如密码、安全问题、硬件设备等）

在丢失device/share的情况下，由于share threshold中内置了冗余，用户可以重构他们的密钥(用户需要证明拥有至少 3 (2/3) 个中的 2 个shares，才能重构密钥)。用户也可以在此基础上增加密钥的share。

在易用性方面，无论是否第一次登录或是更换设备登录都是非常方便，直接使用社交或邮箱登录即可。

不过账户地址的安全性比较低，用户在集成了Web3Auth的应用上登录后，前端可以账户地址的私钥，有了私钥就可以对该账户地址进行任何操作（例如转账、交易等）。

此外，值得注意的是，Web3Auth 并不是钱包，它只是用于身份验证的基础架构。

UniPass（分布式被动托管智能合约钱包）

UniPass 也是一个建立在 MPC 密钥管理之上的智能合约钱包，使用守护邮件 （gardian email）的域名密钥（DKIM）来验证重置请求，而不是使用社交密钥，相比于传统的中心化钱包，UniPass具有更高的安全性和私密性。

DKIM 的身份验证可以通过发送电子邮件简单地完成，整个流程不涉及任何需要授权用户请求的服务器，从而有效地消除了中心化风险。

DKIM： 是一种用于确保电子邮件完整性和可靠性的电子邮件身份验证方法。它通过对发件人在发送邮件时对消息内容进行签名，并在接收邮件时验证签名以确定消息内容是否被改变或者篡改。这使得接收者可以验证邮件的真实来源和内容的完整性。DKIM 通过把发送者的签名附加到消息的头部，并通过一种公钥加密技术在接收邮件时验证签名。

UniPass 之所以被称为“被动托管”，是因为它并不需要用户将私钥交给任何第三方服务进行存储，而是通过智能合约实现一种安全的自我管理方式。这种方式下，用户的私钥是保存在区块链上的，由用户自己掌控，不会被第三方访问或篡改。

使用邮箱协议用到的密码学与链上智能合约交互。

账户智能合约部署流程：创建账户-→账户发生交易-→部署账户智能合约。 UniPass钱包的账户智能合约需要先部署才能使用，因此需要一定的费用支持，这与MetaMask(EOA)钱包不同。（如果账户没有足够的余额来支付智能合约部署所需的 gas 费用，则账户智能合约将无法部署。因此，如果一个账户在收到转账之前没有足够的 ETH 来支付智能合约部署的 gas 费用，那么它将无法部署智能合约并处理转账。在这种情况下，转账交易将会失败，转账的资金将会返还到发送者的账户中。）

兼容ERC-4337协议 （让应用帮助用户支付创建账户的 gas 费，也可以帮助用户代付交易手续费。甚至使用任意的 ERC20 代币支付交易手续费。）

其他智能合约钱包解决方案往往还需要依赖外部( EOA) 钱包做私钥管理。UniPass Wallet 通过多方安全计算（MPC）的签名技术（TSS)，避免了依赖于外部 EOA 钱包的安全性和可用性，同时也实现业务流程中私钥全程可用不可见的高安全性。

如果用户要更换设备需要邮件OTP+密码，不像Web3Auth直接使用社交账号登录即可。UniPass具有高可用性，即使他们官方停止服务，用户也是可以访问他们的钱包。

python版本：3.9.7

eth-brownie版本：1.19.2

一：介绍

本文使用开发语言python，用基于python的开发和测试框架Brownie来开发和部署合约，该空投合约可以对Decentranland Wearables进行批量空投。

二：合约代码

对于infura 项目的创建在本篇文章中一讲到

1: 在Infura中创建一个Polygon的project（Decentranland Wearables在polygon链上）

2：安装eth-brownie

pip install eth-brownie

3： 初始化项目

创建个空文件夹，执行初始化命令，之后会生成一些文件夹

 mkdir air_drop
 cd air_drop
 brownie init

4: 在contracts 文件夹中来创建.sol文件来写入合约代码

cd contracts/
touch air_drop_batch.sol

首先是两个interface基于ERC165和ERC721，这里是固定的直接写入即可，也可以把这两个interface放入文件夹interfaces/中，然后在contracts/air_drop_batch.sol调用，这里我们直接放到一个文件中。

// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts (last updated v4.8.0) (token/ERC721/IERC721.sol)

pragma solidity ^0.8.0;


interface IERC165 {
    /// @notice Query if a contract implements an interface
    /// @param interfaceID The interface identifier, as specified in ERC-165
    /// @dev Interface identification is specified in ERC-165. This function
    ///  uses less than 30,000 gas.
    /// @return `true` if the contract implements `interfaceID` and
    ///  `interfaceID` is not 0xffffffff, `false` otherwise
    function supportsInterface(bytes4 interfaceID) external view returns (bool);
}

/**
 * @dev Required interface of an ERC721 compliant contract.
 */
interface IERC721 is IERC165 {
    /**
     * @dev Emitted when `tokenId` token is transferred from `from` to `to`.
     */
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);

    /**
     * @dev Emitted when `owner` enables `approved` to manage the `tokenId` token.
     */
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);

    /**
     * @dev Emitted when `owner` enables or disables (`approved`) `operator` to manage all of its assets.
     */
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);

    /**
     * @dev Returns the number of tokens in ``owner``'s account.
     */
    function balanceOf(address owner) external view returns (uint256 balance);

    /**
     * @dev Returns the owner of the `tokenId` token.
     *
     * Requirements:
     *
     * - `tokenId` must exist.
     */
    function ownerOf(uint256 tokenId) external view returns (address owner);

    /**
     * @dev Safely transfers `tokenId` token from `from` to `to`.
     *
     * Requirements:
     *
     * - `from` cannot be the zero address.
     * - `to` cannot be the zero address.
     * - `tokenId` token must exist and be owned by `from`.
     * - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}.
     * - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.
     *
     * Emits a {Transfer} event.
     */
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes calldata data
    ) external;

    /**
     * @dev Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients
     * are aware of the ERC721 protocol to prevent tokens from being forever locked.
     *
     * Requirements:
     *
     * - `from` cannot be the zero address.
     * - `to` cannot be the zero address.
     * - `tokenId` token must exist and be owned by `from`.
     * - If the caller is not `from`, it must have been allowed to move this token by either {approve} or {setApprovalForAll}.
     * - If `to` refers to a smart contract, it must implement {IERC721Receiver-onERC721Received}, which is called upon a safe transfer.
     *
     * Emits a {Transfer} event.
     */
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;

    /**
     * @dev Transfers `tokenId` token from `from` to `to`.
     *
     * WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721
     * or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must
     * understand this adds an external call which potentially creates a reentrancy vulnerability.
     *
     * Requirements:
     *
     * - `from` cannot be the zero address.
     * - `to` cannot be the zero address.
     * - `tokenId` token must be owned by `from`.
     * - If the caller is not `from`, it must be approved to move this token by either {approve} or {setApprovalForAll}.
     *
     * Emits a {Transfer} event.
     */
    function transferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;

    /**
     * @dev Gives permission to `to` to transfer `tokenId` token to another account.
     * The approval is cleared when the token is transferred.
     *
     * Only a single account can be approved at a time, so approving the zero address clears previous approvals.
     *
     * Requirements:
     *
     * - The caller must own the token or be an approved operator.
     * - `tokenId` must exist.
     *
     * Emits an {Approval} event.
     */
    function approve(address to, uint256 tokenId) external;

    /**
     * @dev Approve or remove `operator` as an operator for the caller.
     * Operators can call {transferFrom} or {safeTransferFrom} for any token owned by the caller.
     *
     * Requirements:
     *
     * - The `operator` cannot be the caller.
     *
     * Emits an {ApprovalForAll} event.
     */
    function setApprovalForAll(address operator, bool _approved) external;

    /**
     * @dev Returns the account approved for `tokenId` token.
     *
     * Requirements:
     *
     * - `tokenId` must exist.
     */
    function getApproved(uint256 tokenId) external view returns (address operator);

    /**
     * @dev Returns if the `operator` is allowed to manage all of the assets of `owner`.
     *
     * See {setApprovalForAll}
     */
    function isApprovedForAll(address owner, address operator) external view returns (bool);
}

为什么是ERC721？

来随便找个decentranland wearable来看下

接下来就是要写对于空投逻辑处理的合约，接上面代码

contract AirdropBatchNFT{
    event Airdrop721(
        address from,
        address batchContractAddress
    );

    function ERC721AirdropBatch(
        address from,  // 发送wearable用户的地址
        address batchContractAddress,  // 要发送的wearable的合约地址
        uint256[] memory tokenIdSet,  // 发送wearable的tokenid 列表
        address[] memory receivers,  // 接收空投wearable的用户钱包地址列表
    ) public {
        // 判断是否是发送者自己操作
        require(msg.sender == from, "danger sender");   
// 判断发送者是否对本空投合约授权，只有授权空投合约才可以对发送者的wearable进行空投                  require(IERC721(batchContractAddress).isApprovedForAll(msg.sender,   address(this)), "not approve");
        // 接收者列表的长度要与空投的tokenid列表长度一样
        require(tokenIdSet.length == receivers.length, "The length of tokenIdSet is different from the length of receivers");
        // 判断要空投的wearable是否都属于空投者
        for(uint256 j = 0; j < tokenIdSet.length; ++j) {         require(IERC721(batchContractAddress).ownerOf(tokenIdSet[j]) == from, "tokens not enough");
        }
        // 把两个列表中第n个token空投给弟n个接受者
        for(uint256 i = 0; i < receivers.length; ++i) {
            IERC721(batchContractAddress).safeTransferFrom(from, receivers[i], tokenIdSet[i]);
        }

        emit Airdrop721(
            from,
            batchContractAddress
        );
    
}

三：部署

项目根目录创建配置文件

touch brownie-config.yaml

dependencies:
  - OpenZeppelin/openzeppelin-contracts@4.6.0    # 在上文中提到的IERC721&IERC165 可以从OpenZeppelin中导入，这里也指定下版本，只不过上文中是直接填的源码，并不是导入
# 如果使用 openzeppelin 需要下载
# brownie pm install OpenZeppelin/openzeppelin-contracts@4.6.0 
compiler:
  solc:
    version: null
    optimizer:
      enabled: true
      runs: 200
    remappings:
      - '@openzeppelin=OpenZeppelin/openzeppelin-contracts@4.6.0'

# .env 由于WEB3_INFURA_PROJECT_ID和PRIVATE_KEY 存放在文件中
dotenv: .env

networks:
  default: polygon-main
  polygon-main:
    host: https://polygon-mainnet.infura.io/v3/${WEB3_INFURA_PROJECT_ID}  # 上面创建的infura项目的连接
wallets:
  PRIVATE_KEY: ${PRIVATE_KEY}  # 钱包地址的私钥

项目根创建 .env 存放私钥等信息

touch .env

PRIVATE_KEY=xxxxxxxxx
WEB3_INFURA_PROJECT_ID=xxxxxxxxxx

终端执行 brownie compile编译代码，生成abi文件 接下来是部署，如果部署失败原因指定WEB3_INFURA_PROJECT_ID 或是PRIVATE_KEY

1. source .env

2. 检查两个值是否正确

在scripts/中创建depoly.py文件

cd scripts/
touch deploy.py

from brownie import AirdropBatchNFT, config, accounts # AirdropBatchNFT 是合约中的构造函数，项目要以brownie来启动


def get_account():
    return accounts.add(config['wallets']['PRIVATE_KEY'])


def test(account):
    air_drop = AirdropBatchNFT.deploy({'from': account})


def main():
    account = get_account()
    test(account)
    print('account=', account)

接下来执行部署命令

brownie run deploy.py

之后会看到部署的合约地址以及在 build/deployments/map.json中也可以看到部署的纪录

bytecode 可以不填

optimization 以及下方settings中的内容配置可以在 build/depolyments/137/合约地址.json中找到 搜索compiler

这样，Decentranland 空投wearable的合约就完成了！

一：安装

二：使用

1：通过infura链接来与以太坊合约交互

infura截图

连接成功之后我们把本篇文章中的abi与部署的合约地址用到这里

abi文件（rent_nft_test.json）在 brownie_test/build/contracts 中

那么如何获取到该合约中发生得mint/transfer等信息

from web3 import Web3
import json

# 首先通过infura节点链接
w3=Web3(Web3.HTTPProvider('https://<your-provider-url>'))

# 合约abi文件
with open('./brownie_test/build/contracts/ERC4907.json', 'r') as f:
    abi_contract = json.loads(f.read())['abi']

# 与infura节点链接成功后 指定address以及abi与该合约建立连接
# address是合约地址 abi是该合约对应的abi
my_contract = w3.eth.contract(address='0xADD22a3efa6f22dd60DF65CDfE096da0366eE002', abi=abi_contract)

# 现在来测试获取到的该合约的信息
# ownerOf是合约中定义的方法，获取tokenId为1的owner地址，通过functions来调用它
print('token_id 1 owner: 'my_contract.functions.ownerOf(1).call())

# result
>>> token_id 1 owner: 0x60EA96f57B3a5715A90DAe1440a78f8bb339C92e
# 这个地址是在我部署该合约时mint tokenId为1的nft的钱包地址
# 证明获取该合约信息成功

上面获取合约信息成功，下面来给合约进行一次mint事件

接上面代码：

# 要给address去mint一个nft
address = '0x60EA96f57B3a5715A90DAe1440a78f8bb339C92e

# 生成nonce
nonce = w3.eth.getTransactionCount(address)

# mint token id 为 2 的nft，
# 通过functions调用mint

# buildTransaction构建交易字典，以此来传入合约中需要接受得msg.sender（address）
mint = my_contract.functions.mint(2).build_transaction({'from': address, 'nonce': nonce})

# 签名
sign = w3.eth.account.sign_transaction(mint, '钱包地址私钥，在metamask查看')

# 给链上发送这次mint
w3.eth.send_raw_transaction(sign.rawTransaction)

关于nonce：

为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。

在 send_raw_transaction 后去goerli测试官网查看该合约会有一次新的mint记录

再来测试下给该nft设定一个user（租赁此nft的用户）

python：就像发送一次mint请求一样来setUser

from web3 import Web3
import json

# 首先通过infura节点链接
w3=Web3(Web3.HTTPProvider('https://<your-provider-url>'))

# 合约abi文件
with open('./brownie_test/build/contracts/ERC4907.json', 'r') as f:
    abi_contract = json.loads(f.read())['abi']

# 与infura节点链接成功后 指定address以及abi与该合约建立连接
# address是合约地址 abi是该合约对应的abi
my_contract = w3.eth.contract(address='0xADD22a3efa6f22dd60DF65CDfE096da0366eE002', abi=abi_contract)

# nft owner
address = '0x60EA96f57B3a5715A90DAe1440a78f8bb339C92e

# 生成nonce
nonce = w3.eth.getTransactionCount(address)
# 上面代码与上方的一样

# 通过chain.time(来获取链上时间)
from brownie import chain

# 调用setUser 给传入接收的值只有这里与mint是有区别的
# 1: nft tokenId  
# 0x450AF1Ea236932c0e18B53BC1FeB15E47AA292df user地址
# 到期时间
# 到期后这个nft user地址自动清零
x = my_contract.functions.setUser(1, '0x450AF1Ea236932c0e18B53BC1FeB15E47AA292df', 10*60+chain.time()).build_transaction({'from': address, 'nonce': nonce})

signed_txn = w3.eth.account.sign_transaction(x, '钱包地址私钥，在metamask查看')

w3.eth.send_raw_transaction(signed_txn.rawTransaction)

以太坊goerli测试网官网查看数据

此时在代码中查看下tokenId是1的nft的user

print(my_contract.functions.userOf(1).call())

# result
>>>0x450AF1Ea236932c0e18B53BC1FeB15E47AA292df

以上是使用web3.py与智能合约交互的方式，流程如此，如需进行Transfer事件或获取其他信息可以修改mint，ownerOf等（合约中定义的function以及event），也可以查阅官方文档找到更多的操作。

一：

首先在infura创建一个项目

二：

（如果读过本篇文章的话可以忽略下面这个步骤）

初始化brownie项目编译合约代码

1. 执行 brownie init

2. 编写合约代码

   // SPDX-License-Identifier: MIT
   pragma solidity ^0.8.0;
   
   import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
   import "@openzeppelin/contracts/utils/Counters.sol";
   import "../interfaces/IERC4907.sol";
   
   contract ERC4907 is ERC721, IERC4907 {
       struct UserInfo
       {
           address user;   // address of user role
           uint64 expires; // unix timestamp, user expires
       }
   
       mapping (uint256  => UserInfo) private _users;
   
       constructor()
        ERC721("RentNFTTest","RNT"){
   
        }
   
       /// @notice set the user and expires of a NFT
       /// @dev The zero address indicates there is no user
       /// Throws if `tokenId` is not valid NFT
       /// @param user  The new user of the NFT
       /// @param expires  UNIX timestamp, The new user could use the NFT before expires
       function setUser(uint256 tokenId, address user, uint64 expires) public override virtual{
           // 判断msg.sender是否是该token的owner
           require(_isApprovedOrOwner(msg.sender, tokenId), "ERC4907: transfer caller is not owner nor approved");
   
           // 设置 租赁者以及到期时间
           UserInfo storage info = _users[tokenId];
           info.user = user;
           info.expires = expires;
           // 更新该token的User
           emit UpdateUser(tokenId,user,expires);
       }
   
       /// @notice Get the user address of an NFT
       /// @dev The zero address indicates that there is no user or the user is expired
       /// @param tokenId The NFT to get the user address for
       /// @return The user address for this NFT
       function userOf(uint256 tokenId) public view override virtual returns(address){
           if( uint256(_users[tokenId].expires) >=  block.timestamp){
               return _users[tokenId].user;
           }
           return address(0);
       }
   
       /// @notice Get the user expires of an NFT
       /// @dev The zero value indicates that there is no user
       /// @param tokenId The NFT to get the user expires for
       /// @return The user expires for this NFT
       function userExpires(uint256 tokenId) public view override virtual returns(uint256){
           return _users[tokenId].expires;
       }
   
       /// @dev See {IERC165-supportsInterface}.
       function supportsInterface(bytes4 interfaceId) public view virtual override(ERC721) returns (bool) {
           return interfaceId == type(IERC4907).interfaceId || super.supportsInterface(interfaceId);
       }
   
       function mint(tokenId) public returns (uint256){
           _safeMint(msg.sender, tokenId);
           return tokenId;
       }
   }
   

代码在这篇文章功能测试已经提到，这里直接搬过来用

1. 配置 brownie-config.yaml

2. 执行 brownie compile来编译生成abi文件等

在之前的基础上配置brownie-config.yaml

dotenv: .env
networks:  #  指定使用 goerli测试网 WEB3_INFURA_PROJECT_ID是上方infura截图中框出的api_key
  goerli:
    host: https://goerli.infura.io/v3/${WEB3_INFURA_PROJECT_ID}
wallets:
  PRIVATE_KEY: ${PRIVATE_KEY}   # 钱包地址的私钥，因为比较重要通过导入.env

在项目目录中创建一个.env

在 scripts/ 中创建一个脚本 depoly.py

from brownie import ERC4907, accounts, config
import brownie


def get_account():
    # 要部署到测试网络不在本地，添加账户对象
    # config数据来自brownie-config.yaml
    return accounts.add(config['wallets']['PRIVATE_KEY'])


def test_mint(account):
    mint_nft = ERC4907.deploy({'from', account})
    mint_nft.mint(1, {'from': account})
    # 查看mint nft 之后的owner
    print('nft token_id owner/minter:', mint_nft.ownerOf(1))


# 一定要有main()函数作为程序的入口
def main():
    account = get_account()
    print('account=', account)
    test_mint(account)

此时执行brownie run scripts/depoly.py

mint之后可以看到nft的owner是我的账户

查看以下brownie自带的部署的网络，这里使用goerli，如果没有要用到的网络可以自己添加，具体操作可以查看brownie文档

部署

获取测试币

部署的话需要交gas费，这样需要到goerli的水龙头获取一些测试币

把metamask网络设置成goerli测试网

这个地址包含多种获取测试币的方式

https://faucetlink.to/goerli

这个地址是我看到的给的比较多的

https://faucets.chain.link/

然后将此合约部署到以太坊goerli测试网

brownie run scripts/depoly.py --network goerli

拿着合约地址到以太坊测试网查看下

第二行记录是创建这个合约的记录

第一行mint记录是depoly.py中mint nft的记录

这样就代表合约部署成功。

这篇文章讲到什么是EIP-4907，EIP-721，ERC-20

二：Brownie

一：介绍

Brownie 是一个基于 Python 的智能合约开发和测试框架。Brownie项目严重依赖web3.py

二：用法

安装

1. pip install eth-brownie

2. npm install ganache-cli@latest --global

   （ganache-cli 会启动本地的以太坊测试网络便于我们测试，终端输入ganache-cli会看到一些测试账号私钥等信息）

安装成功后创建一个空文件夹（例如名为：brownie_test）

进入文件夹中执行brownie init

成功之后生成以下文件夹

• contracts/: 用于存放要部署的智能合约

• interfaces/: 用于存放接口，被智能合约调用

• scripts/: 用于部署和交互的脚本

• tests/: 用于测试项目的脚本

• build/：存放项目数据，例如编译合约后的abi和单元测试结果

• reports/：用于 GUI 的 JSON 报告文件

接下来编写继承自EIP-721和EIP-4907合约代码

首先将EIP-4907接口代码放到interfaces/

然后我们在contracts/ 创建一个名为rent_test.sol文件写入以下代码

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "../interfaces/IERC4907.sol";

contract ERC4907 is ERC721, IERC4907 {
    struct UserInfo
    {
        address user;   // address of user role
        uint64 expires; // unix timestamp, user expires
    }

    mapping (uint256  => UserInfo) private _users;

    constructor()
     ERC721("RentNFTTest","RNT"){

     }

    /// @notice set the user and expires of a NFT
    /// @dev The zero address indicates there is no user
    /// Throws if `tokenId` is not valid NFT
    /// @param user  The new user of the NFT
    /// @param expires  UNIX timestamp, The new user could use the NFT before expires
    function setUser(uint256 tokenId, address user, uint64 expires) public override virtual{
        // 判断msg.sender是否是该token的owner
        require(_isApprovedOrOwner(msg.sender, tokenId), "ERC4907: transfer caller is not owner nor approved");

        // 设置 租赁者以及到期时间
        UserInfo storage info = _users[tokenId];
        info.user = user;
        info.expires = expires;
        // 更新该token的User
        emit UpdateUser(tokenId,user,expires);
    }

    /// @notice Get the user address of an NFT
    /// @dev The zero address indicates that there is no user or the user is expired
    /// @param tokenId The NFT to get the user address for
    /// @return The user address for this NFT
    function userOf(uint256 tokenId) public view override virtual returns(address){
        if( uint256(_users[tokenId].expires) >=  block.timestamp){
            return _users[tokenId].user;
        }
        return address(0);
    }

    /// @notice Get the user expires of an NFT
    /// @dev The zero value indicates that there is no user
    /// @param tokenId The NFT to get the user expires for
    /// @return The user expires for this NFT
    function userExpires(uint256 tokenId) public view override virtual returns(uint256){
        return _users[tokenId].expires;
    }

    /// @dev See {IERC165-supportsInterface}.
    function supportsInterface(bytes4 interfaceId) public view virtual override(ERC721) returns (bool) {
        return interfaceId == type(IERC4907).interfaceId || super.supportsInterface(interfaceId);
    }

    function mint(uint256 tokenId) public returns (uint256){
        _safeMint(msg.sender, tokenId);
        return tokenId;
    }
}

配置brownie-config.yaml

终端运行：
brownie pm install OpenZeppelin/openzeppelin-contracts@v4.6.0
创建 brownie-config.yaml(brownie配置文件)

在brownie-config.yaml中写入以下代码

dependencies:
  - OpenZeppelin/openzeppelin-contracts@4.6.0
compiler:
  solc:
    version: null
    optimizer:
      enabled: true
      runs: 200
    remappings:
      - '@openzeppelin=OpenZeppelin/openzeppelin-contracts@4.6.0'

终端执行 brownie compile 进行编译

该命令会将 contracts 目录下所有的智能合约都进行编译，编译完成后，在 build/contracts和interfaces 中会出现同名的 json 文件，包含bytecode和abi等信息

编写测试合约代码

接下来在 tests/ 目录下创建一个名为 test_rentable.py 的文件（文件名必须符合test_*.py / *_test.py的格式）

在文件中要测试到的方法函数需要以test为前缀，例如下面的test_nft

编写代码，brownie使用pytest来测试

# brownie中并没有ERC4907，这个是我们合约中定义的名字（contract ERC4907 is ERC721, IERC4907...）所以不论运行和测试都要在终端以brownie的命令来做
from brownie import ERC4907, accounts, chain 
import brownie
import pytest
from web3.constants import ADDRESS_ZERO
DAY = 24 * 60 * 60


# scope="module"设置该方法在测试的时候只执行一次test_nft()
@pytest.fixture(scope="module") 
def test_nft():
    global deployer, owner, user
    deployer, owner, user = accounts[0:3]
  
    # 可以说是这里对合约中的ERC4907进行实例化，然后调用其中定义的function
    testNft = ERC4907.deploy({'from': deployer}) 

    return testNft


def test_mint(test_nft):
    # Mint Nft
    # 1 为 合约中 mint 接受的tokenId参数， {"from": owner} 中owner 则是msg.sender
    test_nft.mint(1, {"from": owner})  
    print(f'Minted NFT ( TokenId : {1} )')

    # 验证owner账户上的nft数量，如果是1个的话证明mint成功
    assert test_nft.balanceOf(owner.address) == 1

    # 验证 tokenId是1的nft 的owner是否与我们这里定义的owner相同
    assert test_nft.ownerOf(1) == owner.address

终端执行 brownie test ，以下代码测试同理

接下来mint成功之后接着上面的代码来测试租赁

def test_renting(test_nft):
    # 设置租赁两天
    rent_expire_time = chain.time() + 2 * DAY

    # 设置 租赁的nft的tokenId, user, 以及租赁时间
    # 合约代码中会判断tokenId为1的owner（应该是我们上方mint此nft的地址）地址是否等于msg.sender, 而msg.sender是由{"from": owner.address}传过去，因为只有该nft的owner才有权力租
    test_nft.setUser(1, user1.address, rent_expire_time, {"from": owner.address})

    # 租出去之后再次查看下nft的owner变没变
    assert test_nft.ownerOf(1) == owner1.address

    # 验证租该nft用户的地址
    assert test_nft.userOf(1) == user1.address

    # 验证租nft的到期时间
    assert test_nft.userExpires(1) == rent_expire_time

测试下不是owner进行租赁（设置uesr），接着上面代码继续

def test_user_nft_transfer(test_nft):
    # 对于user不可以有transfer的权限
    # 使用brownie.reverts来捕捉代码中报出的错误。由于{"from": user.address}（合约以msg.sender来接收，判断tokenId=1的owner是否与msg.sender相同），这里safeTransferFrom返回我们捕捉到的错误证明判断成功，而代码会继续向下执行，如果返回的错误和我们捕捉的不一样该代码会测试失败
    with brownie.reverts("ERC721: transfer caller is not owner nor approved"):
        testNft.safeTransferFrom(owner.address, user.address, 1, {"from": user.address})

测试租赁到期后是否还有user

def test_renting_expired(testNft):
    # 假定两天后的时间点
    chain.sleep(2 * DAY + 1)
    chain.mine(1)

    # 来看一下当前的时间是否过了租赁到期时间
    assert testNft.userExpires(1) < chain.time()

    # 到期后此nft的user为0x0000000000000000000000000000000000000000
    assert testNft.userOf(1) == ADDRESS_ZERO

测试成功后结果都为passed

如果需要其他的判断逻辑使合约更严谨可以在代码中加入判断，基于EIP4907简单的实现就是这样。

介绍

首先看看什么是ERC-20

ERC -- Ethereum Request for Comment 的缩写，用于对代币和以太坊生态系统提出改进建议。

ERC-20 是加密货币行业中最流行的代币标准。一类相同的代币，一个简单的接口，允许开发者在以太坊区块链之上创建他们的代币。通俗的讲 ERC-20 代币就像我们生活中钞票一样，可互换代币具有等值单位的相同资产

其次

EIP-721 则是不可替代的代币标准，是一类独特的令牌(Token)。就像所有的房子，收藏品等都是不同的，都有唯一的。

生活中我们用人民币/美元等买房子/车，这里我们可以说用符合ERC-20标准的代币去买一个符合EIP-721协议的NFT (例如使用ETH/USDC购买Voxels/Decentraland中的一块土地)，而这只购买，在购买之后NFT的owner也就改变，ERC-721中并没有实现可以租赁的功能

EIP-4400和EIP-4907就是基于ERC-721的扩展，增加角色来达到可租赁的目的

EIP-4400引入了consumer角色，对于引入这个角色需求也就源于这样一个事实。除了NFT的owner之外还可以有其他角色来对房子等NFT进行装饰使用，那么这个consumer被设置之后也就可以对该NFT进行使用装饰等操作

EIP-4400代码 增加了1个event和2个function分别是 ：

• 当NFT的owner改变了consumer的时候发出，如果NFT的owner改变了那么consumer也就设置为空了

• 获取该NFT的consumer

• 更改NFT的consumer

/// @title EIP-721 Consumer Role extension
///  Note: the EIP-165 identifier for this interface is 0x953c8dfa
interface IEIP721Consumable /* is EIP721 */ {
  
    /// @notice Emitted when `owner` changes the `consumer` of an NFT
    /// The zero address for consumer indicates that there is no consumer address
    /// When a Transfer event emits, this also indicates that the consumer address
    /// for that NFT (if any) is set to none
    event ConsumerChanged(address indexed owner, address indexed consumer, uint256 indexed tokenId);

    /// @notice Get the consumer address of an NFT
    /// @dev The zero address indicates that there is no consumer
    /// Throws if `_tokenId` is not a valid NFT
    /// @param _tokenId The NFT to get the consumer address for
    /// @return The consumer address for this NFT, or the zero address if there is none
    function consumerOf(uint256 _tokenId) view external returns (address);

    /// @notice Change or reaffirm the consumer address for an NFT
    /// @dev The zero address indicates there is no consumer address
    /// Throws unless `msg.sender` is the current NFT owner, an authorised
    /// operator of the current owner or approved address
    /// Throws if `_tokenId` is not valid NFT
    /// @param _consumer The new consumer of the NFT
    function changeConsumer(address _consumer, uint256 _tokenId) external;
}

EIP-4907也引入了一个角色称为user，而且在这个基础之上增加了过期时间，当NFT租赁时间到期时会自动结束使用期限，不用第二次交易，这样就会节省gas费，而在之前的租赁当中NFT的owner要提交两笔链上交易，一笔在期限开始时将新地址列为新用户角色，另一笔在结束时收回用户角色

• 更新user

• 设置user

• 获取user

• 获取过期时间

  在更新user和设置user的时候传入过期时间

interface IERC4907 {

    // Logged when the user of an NFT is changed or expires is changed
    /// @notice Emitted when the `user` of an NFT or the `expires` of the `user` is changed
    /// The zero address for user indicates that there is no user address
    event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires);

    /// @notice set the user and expires of an NFT
    /// @dev The zero address indicates there is no user
    /// Throws if `tokenId` is not valid NFT
    /// @param user  The new user of the NFT
    /// @param expires  UNIX timestamp, The new user could use the NFT before expires
    function setUser(uint256 tokenId, address user, uint64 expires) external;

    /// @notice Get the user address of an NFT
    /// @dev The zero address indicates that there is no user or the user is expired
    /// @param tokenId The NFT to get the user address for
    /// @return The user address for this NFT
    function userOf(uint256 tokenId) external view returns(address);

    /// @notice Get the user expires of an NFT
    /// @dev The zero value indicates that there is no user
    /// @param tokenId The NFT to get the user expires for
    /// @return The user expires for this NFT
    function userExpires(uint256 tokenId) external view returns(uint256);
}

EIP-4400和EIP-4907的区别

相同点：

• 都是为了NFT的租赁而出现的

• 都是基于EIP721的扩展在此基础之上实现了新增的功能

• 都增加了一个使用者的角色，在EIP4400中称为consumer，在EIP4907中称为user，而这个对应的就是租赁者

• 在lender想租出自己的NFT，把NFT挂到租赁平台租出去时，lender的NFT会被转移到合约平台的合约地址当中，此时合约平台会再给lender增加可以操作此NFT的权限以便在有人租赁此NFT之前lender可以继续使用自己的NFT

不同点：

• 在增加使用者角色之上EIP4907又增加了一个userExpires，在租赁到期时间无需再进行第二次交易

LandWorks是基于EIP-4400租赁，而Double protocal是基于EIP-4907

这篇文章对于使NFT可租赁的方法进行了讲解

对于如何基于EIP-4907实现租赁，这篇文章做了讲解

https://mirror.xyz/0x450AF1Ea236932c0e18B53BC1FeB15E47AA292df/VW2cNhU45VQu-7oJBBNkpZUdPcspW2bjvugIPv_AyZs

一：Typesense介绍

Typesense将数据保存在磁盘当中，建立的索引保存内存中

Typesense是一个开源的、有容错能力的搜索引擎，针对实时（通常低于 50 毫秒）搜索即键入体验和开发人员生产力进行了优化。

Typesense做了一个对于其他搜索引擎的对比。（文档版，表格版）

索引数据速度以及资源占用：

对于220万份食谱（一份食谱相当于下文中提到的一个document）

• 在 Typesense 中进行索引时占用了大约 900MB 的 RAM(内存)

• 花了 3.6 分钟索引所有 220 万条记录

• 在具有 4 个 vCPU 的服务器上，Typesense 每秒能够处理104 个并发搜索查询，平均搜索处理时间为11毫秒。

RAM(内存)方面：如果数据量为 X MB大小，则需要占用2X-3XRAM（2-3倍数据量大小的占用）

如需深入了解可以查阅官方文档

二：Typesense的用法

1：使用typesense有两种方法

• 使用自带的云服务，配置运行简单（收费）

• 在本地安装typesense，自己维护配置（本文使用这种方法）

2：安装启动typesense

（1）：下载并安装

centos:（如果您的系统不是centos可以在官方文档中找到对应的下载方法

curl -O https://dl.typesense.org/releases/0.23.1/typesense-server-0.23.1-1.x86_64.rpm
sudo yum install ./typesense-server-0.23.1-1.x86_64.rpm

（2）：启动服务查看状态

如果从rpm包中安装typesense会自动启动服务，使用下面命令查看服务状态

sudo systemctl status typesense-server.service

Active 是 running 则代表已启动

• 配置文件位于/etc/typesense/typesense-server.ini

• 日志在/var/log/typesense/

• 数据目录在/var/lib/typesense/

日志目录和数据目录可以在配置文件中更改

（3）：服务启动后检查是否可以接收到请求

curl http://localhost:8108/health
{"ok":true}

（4）：安装client

这是python版本的，如果需要其他版本可以在官网上查看

3：构建数据集用于检索

（1）：下载一份测试数据

数据来源typesense官网 用于测试，如果自己有测试数据直接使用即可

cd /typesense_test    # 任意目录 
curl -O https://dl.typesense.org/datasets/books.jsonl.gz
gunzip books.jsonl.gz

（2）：初始化client

import typesense

client = typesense.Client({
  'nodes': [{
    'host': 'localhost', # For Typesense Cloud use xxx.a1.typesense.net
    'port': '8108',      # For Typesense Cloud use 443
    'protocol': 'http'   # For Typesense Cloud use https
  }],
  'api_key': '<API_KEY>',    # api-key 在 一-->2-->（2）中提到的配置文件中可以查看
  'connection_timeout_seconds': 2  
})

这样就可以和typesense交互了

以下代码都是在建立交互的基础上运行

（3）：创建存放书籍数据的collection

在 typesense 中，一个 collection 相当于关系型数据库中的一张表

而 Documents 相当于表中的每条数据

创建一个 collection 时需要指定一些字段名和类型

（继续初始化代码，在初始化后：）

（如果使用自己数据需要根据数据的值类型来设置collection fields中的name type等）

books_schema = {
  'name': 'books',    # collection 的名字，对该集合操作都是根据该名字
  'fields': [
    {'name': 'title', 'type': 'string' },
    {'name': 'authors', 'type': 'string[]', 'facet': True },  ###'facet': True facet字段被逐字索引
    {'name': 'publication_year', 'type': 'int32', 'facet': True },
    {'name': 'ratings_count', 'type': 'int32' },
    {'name': 'average_rating', 'type': 'float' }
  ],
  'default_sorting_field': 'ratings_count'  # 在没有sort_by时检索结果默认以ratings_count字段排序
}

client.collections.create(books_schema)

######## 字段类型
type	描述
string	字符串值
string[]	字符串数组
int32	整数值高达 2,147,483,647
int32[]	数组int32
int64	大于 2,147,483,647 的整数值
int64[]	数组int64
float	浮点数/十进制数
float[]	浮点数/十进制数数组
bool	true或者false
bool[]	布尔数组
geopoint	纬度和经度指定为[lat, lng]
geopoint[]	纬度和经度数组指定为[[lat1, lng1], [lat2, lng2]]
string*	string自动将值转换为 a或的特殊类型string[]。   ###如果传入的值为1，那么会自动转化成 ‘1’
auto	自动尝试根据添加到集合中的文档推断数据类型的特殊类型。请参阅自动模式检测。

（4）：添加数据

在创建完成后需要向里面添加数据，将刚刚下载好的测试数据添加到collection中

with open('/typesense_test/books.jsonl') as jsonl_file:
  client.collections['books'].documents.import_(jsonl_file.read().encode('utf-8'))    # books--collection中定义的name

或者自己有数据需要向里面添加

## 导入单条数据
document = {
  'id': '124',    ### 可以指定，也可以不指定，不指定的情况下就按自增的来
  'company_name': 'Stark Industries',    ### 以下字段是需要包含在collection中的字段，就相当于往数据表中添加数据，指定每个字段的值，如果collection中的有a字段在document中没有指定a字段的值，那么该条document在collection中没有a字段，在以后更新的时候可以再写入
  'num_employees': 5215,
  'country': 'USA'
}

client.collections['collection_name'].documents.create(document)

## 导入多条数据 数据集 在数据量比较大的情况下 这个方法效率很高
documents = [{
  'id': '124',
  'company_name': 'Stark Industries',
  'num_employees': 5215,
  'country': 'USA'
}]

# IMPORTANT: Be sure to increase connection_timeout_seconds to at least 5 minutes or more for imports,
#  when instantiating the client

client.collections['collection'].documents.import_(documents, {'action': 'create'})
action
 create  创建一个新的document，如果collection中有了相同的id，则创建失败
 update  更新一个document，如果没有指定id，则更新失败
 upsert  创建一个新document，或者在有该id的情况下更新该id的数据，需要发送整个document
 emplace 创建一个新document，或者在有该id的情况下更新该id的数据，可以发送部分document或整个document

（5）： 搜索数据

单个collection搜索

 
search_parameters = {
  'q'         : 'harry potter',  # 搜索词
  'query_by'  : 'title',          # 从title字段中检索
  'sort_by'   : 'ratings_count:desc'  # 将搜索结果按ratings_count倒排
}

client.collections['books'].documents.search(search_parameters)

多个collection一起搜索

search_requests = {
  'searches': [
    {
      'collection': 'books',
      'query_by': 'title, authors'  #
    },
    {
      'collection': 'collection_name1',  
      'query_by': 'field1, field2, field3'
    },
    {
      'collection': 'collection_name2',
      'query_by': 'field1'
    }
  ]
}

common_search_params = {
    'q': 'xxxx'    # 搜索词   相同的内容可以放在这里面，代表从每个collection中检索该词  如果query_by 都相同的情况下也可放在这里，把上面的去掉
}

client.multi_search.perform(search_requests, common_search_params)

对于搜索结果的处理以及排序方式还有疑问可以查阅官方文档

（6）：查看 collection 和 document

查看collection，返回collction结构（例如数据表的结构）

# 单个collection
client.collections['collection_name'].retrieve()

# 所有collection
client.collections.retrieve()

查看 document 数据

# 查看document
client.collections['collection_name'].documents['124'].retrieve() # 查看该collection中id为124的document的数据

（7）：更改 collection 和 document

更改collection结构

update_schema = {
  'fields': [    
    {
      'name'  :  'num_employees',
      'drop'  :  True    ## 删除该字段
    },
    {
      'name'  :  'company_category',
      'type'  :  'string'
    }
  ]
}
client.collections['collection_name'].update(update_schema)

更新document数据

document = {
  'company_name': 'Stark Industries',
  'num_employees': 5500
}

client.collections['collection_name'].documents['124'].update(document)  ## 更新documentid为124的数据

（8）：删除 collection 和 document

删除 collection

client.collections['collection_name'].delete()

删除 document

client.collections['collection_name'].documents['124'].delete()  # 删除 id为124的document

注：官方文档api

Graph 根据subgraph描述（称为subgraph.graphq）学习什么以及如何索引以太坊数据。子图描述定义了subgraph感兴趣的智能合约，这些合约中要关注的事件，以及如何将事件数据映射到 The Graph 将存储在其数据库中的数据。

该流程遵循以下步骤：

• 去中心化应用程序通过智能合约上的交易将数据添加到以太坊。

• 智能合约在处理交易时发出一个或多个事件。

• Graph Node 不断地扫描以太坊以寻找新的块以及它们可能包含的子图的数据。

• Graph Node 在这些块中为您的子图查找 Ethereum 事件并运行您提供的映射处理程序。映射是一个 WASM 模块，它创建或更新 Graph Node 存储的数据实体以响应以太坊事件。

• 去中心化应用程序使用节点的GraphQL 端点查询 Graph 节点以获取从区块链索引的数据。Graph 节点反过来将 GraphQL 查询转换为对其底层数据存储的查询，以便利用存储的索引功能获取此数据。去中心化应用程序在丰富的 UI 中为最终用户显示这些数据，他们使用这些数据在以太坊上发布新交易。循环重复

  (来自The graph官网)

一：工具

• 1： The Graph

• 2： OpenSea api

• 3：Python

二：流程

• 1：使用The Graph编写Subgraph来获取各个平台最新的 transfer 的parcel id, tx_hash等信息

• 2：使用python调用在 the graph 中编写的subgraph获取最新的 transfer 的 parcel id

• 3：通过opensea api 获取该 parcel id 的交易详细数据

三：用法(以otherside为例)

1：The Graph

（1）：创建Subgraph

在 The Graph Subgraph页面创建Subgraph

选择Indexed Chain（我这里选择以太坊主网）→ Subgraph名字 → continue

（进入创建的Subgraph页面右侧会有流程指南）

首先安装 the graph cli

命令执行成功后，输入graph，有以下提示代表安装成功。

在本地创建Subgraph项目（otherside是项目名字)

回车之后在选择Ethereum network这里选择mainnet (刚刚在The Graph官网创建的选择Ethereum Mainnet)

其余的默认即可。

(2): 编写代码

创建项目成功之后进入到项目目录使用VSCode编辑代码

-- 整体编写分两步：

-- 第一步：只需要关心schema.graphql和subgraph.yaml两个文件的作用以及用法。

-- 第二步：需要知道 ./src/contract.ts 的作用以及用法

schema.graphql：

定义子图的schema。 GraphQL schema是使用 GraphQL 接口定义语言定义的。 需要具体了解GraphQL schema可以查看参考文档 GraphQL API 。

直白的讲，我们在该文件定义好每个实体（下图 Transfer和Parcel）之后，The Graph官网的项目中也就会暴露出我们代码中定义的实体

根据这些查询参数要获取想要的信息

schema.graphql在定义好之后只是一个用于我们查询的模板。但是数据从哪里来以及如何匹配，就需要用到subgraph.yaml 和 ./src/contract.ts

subgraph.yaml：

定义了subgraph索引的智能合约，这些合约中需要关注的事件，以及如何将事件数据映射到 Graph 节点存储并允许查询的实体。

(创世块的查找：在ethscan中输入otherside合约地址)

eventHandlers：

Transfer 对应abi中的Transfer事件

handleTransfer 对应 ./src/contract.ts中我们定义的function（在下文会提到），现在先写到这里

写好schema.graphql和subgraph.yaml之后回到终端执行graph codegen命令

./src/contract.ts:

最后一步来做数据的匹配

代码完成之后回到The Graph官网创建的项目中，继续右侧的流程，执行最后一步

之后在The Graph官网会看见自己的版本号

当进度条到100%后代表otherside从设置的创世块到目前最新的块的数据都已经匹配到，如果有新块生成同样也会自动匹配

(3): 使用部署的subgraph

至此 the graph 的 subgraph已经部署完成。

使用python来请求数据

2：python

python这里不多做解释，使用requests来请求接口

import requests
url = "创建的subgraph -->detail中的DEVELOPMENT QUERY URL"
query = """
      {
        transfers(orderBy: date, orderDirection: desc, first: 50){
          id
          date
          parcel{
            id
          }
        }
      }
"""
requests_res = requests.post(url, json={'query': query})

3：opensea api

使用 opensea api 获取交易的数据需要4个参数

token_id: parcel id （the graph 获取的 parcel id---例如上张图片中的 “74425”）

asset_contract_address: 平台的合约地址*（otherside：0x34d85c9cdeb23fa97cb08333b511ac86e1c4e258）*

event_type: 用于检索我们获取该parcel id什么类型的数据 （在the graph编写subgraph中获取的是transfer事件的信息，我们通过这个参数来检索获取交易的信息。）由于目的要获取交易数据，所以选择successful。

API-KEY: 需要向opensea平台申请！

调用方法同样使用python requests，再经过处理获取出buyer,seller，交易金额等数据 ，也可以从返回的数据中获取其他需要的数据。

4：总结概括：

由于部署了subgraph之后，会自动实时匹配链上新的块的信息。所以可以使用python写一个脚本，然后放到crontab中来定时调用该接口以获取新的transfer的parcel id，再用opensea event_type中的successful参数过滤出交易的信息（因为subgraph中定义的实体Transfer的id是txhash--唯一值，可以使用它来记录每一次取到最新值的位置）

注： 开发过程中参考的文档

• The Graph 官方文档

• Cryptovoxels Parcels源码