(1) **激励机制**验证交易，有时需要“质押”或金钱存款。
(2) **数据处理器** 将数据和元数据存储在区块链上，确保未来所有的用途都能访问，而不仅限于此智能合约。
(3) 根据预定义的训练算法更新机器学习模型。除了添加数据，任何人都可以查询模型进行预测，激励机制可能会被触发，向用户提供奖励。
以下是两个与“比特币”相关的推文的例子：
1. 第一个推文是英文的，即使包含 #Bitcoin 标签，也很容易被计算模型处理。
2. 在第二个推文中，“Flatbread” 用来指代比特币，在英文中不明显，但在中文中众所周知。
在这种情况下，这两条推文都会通过验证节点的预测过程，并标记为BTC，添加到数据集中去微调共享的可更新模型。通过收集和验证更多的数据集，模型会随着新数据的加入而变得更强大。
**基于质押的自我评估机制**
在理想框架下，对提交错误数据进行罚款或惩罚是最优选择。常见的评估数据质量的方法是利用同行验证，这在传统的众包模型中广泛使用。然而，通过智能合约在提交后执行处罚存在一些挑战。质押机制在数据提交时被整合，以简化惩罚实施的流程。
一个专门部署的模型，称为h，在验证新提交的数据时至关重要。需要注意的是，该模型必须经过初步训练，确保其能够以合理的精度对数据输入进行分类。该过程包括以下几个关键步骤：
* **模型部署**：引入模型h，它基于部分数据预先训练，并用于验证过程。
* **质押要求**：每次数据提交时都需质押，数据x及其关联标签y被记录在区块链上，确保数据和元数据的安全性，推动数据贡献的责任感和质量。
* **退款**：当一定时间t过去后，如果当前模型h仍然同意最初提交的分类，即如果h(x) == y，那么贡献者可以取回其全部质押金额d。
– 假定(x, y)是“好”数据。
– 质押金额的成功返还应记录在贡献者钱包地址的积分中。
• 假设: 已经在退款阶段有数据被验证的贡献者可以定位数据点(x, y)，如果h(x) != y，他们可以申请取回质押金额的一部分。
如果提交的样本(x, y)是错误的或无效的，在时间t内，其他贡献者应提交(x, y0)，其中y0是正确的或更广泛接受的x标签，且y0 != y。这类似于人们通常希望维基百科上的错误编辑能及时被修正。
* **领取押金**：在退款阶段已通过验证的贡献者，可以识别数据项 (x, y)，当模型的输出与其不一致时，有权发起请求，领取最初为 (x, y) 提交的押金部分。该机制旨在激励系统内数据完整性的维护。当提交的数据集被认为不正确或无效时，将分配一个定义的时限，供其他网络参与者通过提交 (x, y') 提出修正建议，其中 y' 代表与 y 不同的正确或广泛接受的标签。此过程类似于维基百科上协作编辑和修正的动态，确保能够快速纠正不准确之处。
**退款等待时间**：在智能合约框架内，时间参数 ( t ) 是一个关键的时间限制，它规定了贡献者在发起退款申请前必须等待的时长。这个时长必须足够长，以便其他网络参与者能够提出带有替代标签的修正数据，以纠正数据中的不一致之处。例如，将 ( t ) 设置为至少一周可以促进这一过程。这种延迟对于敏感度较低的模型尤为重要，因为它提供了足够的时间，允许模型在收集多样化样本后适应新的场景。
高敏感度模型面临着一个独特的挑战，因为它们可能会允许为不准确的数据过早申请退款，可能在其他贡献者有机会进行纠正之前就完成。为缓解这一风险，这些模型需要显著更高的押金要求，以阻止快速或恶意的提交。在决定 ( t ) 值之前，必须经过严格测试和仔细考量，以确保它在平衡模型敏感性和数据准确性需求方面设置得最为合理。
该参数 ( t ) 不必是静态的。其时长可以根据多个因素动态调整，例如数据样本的性质、提交频率或模型对数据准确性的置信度。例如，如果模型能够量化提交正确性的概率，那么这一概率度量可以作为减少 ( t ) 的依据，特别是当模型对提交的有效性具有高度置信时，这表明后续的更改不太可能发生。
**质押的变化：** 系统中的质押机制有多个目的：
* 注入价值，奖励那些贡献准确数据的参与者，激励高质量信息的提交。
* 防止模型的频繁修改，保持系统的稳定性和可靠性。
* 减少垃圾数据（错误或无效数据）的涌入，提升整体数据的完整性。
为了实现这些目标，我们使用特定的公式来确保在短时间内提交大量更新会变得昂贵。这样做是为了给模型的用户提供更加一致和可靠的体验。
一个具体的例子可以说明这一原则：我们期望个人助理设备能对一天内多次发出相同的语音命令给出一致的回应，例如请求播放新闻的指令。
**领取他人的押金**：我们引入了一些指南，供贡献者报告“错误”数据，以从原始贡献者c处提取部分押金。请注意，贡献的数据及其元数据可以在数据处理器或触发的事件中找到。
首先，以下是一些定义：
* 令( r(Cr, d) ) 表示报告数据 ( (x, y) ) 并且押金为( d ) 时，报告者 ( cr ) 所获得的奖励。
* 令( n(c) ) 表示贡献者( c ) 已获得退款的数据样本数（假设为“良好”数据）。
指南：
* 如果( h(x) != y )，表示当前模型与标签不符，因此假定该数据是“错误的”。
* ( n(cr) > 0 )：报告者应该已经提交过“良好”数据并获得退款。这确保他们在尝试从系统获利之前，已经提交了“良好”数据。
* ( cr \neq c )：报告者不能是原始贡献者，否则贡献者可以轻易尝试为“错误”数据取回押金。
* 奖励应在“良好”的贡献者之间共享。
– 这可以防止Sybil攻击，即贡献者通过使用第二个账户取回其全部押金。尽管他们仍可以通过另一个账户取回部分奖励，但必须等待，并通过提交一些“良好”数据获得退款。
* r(cr,d)>ε>0：奖励应至少达到一定的最低值，以覆盖潜在的交易成本。
* 数据处理器必须追踪可领取的剩余押金， 𝑑 𝑟 ≤ 𝑑 dr≤d。
* 由于 ( n(c) ) 随着时间的推移而变化，报告者在索取其 ( d ) 的份额时，(3) 中的比率也会发生变化。因此，某些报告者可能会获得较小比例的 ( d )。我们将在 III-C5 中讨论对此问题的一些可能解决方案。
**模型偏见**：在提议的系统下，存在一种潜在风险，即贡献者在提交数据时主要提交与当前模型预测（ ）一致的数据，期望模型在退款期间能够保持这种一致性。这种策略可能无意中在模型中引发确认偏见，使其倾向于重申之前遇到的数据。尽管要求贡献者支付交易费用，从而在存入和取回退款时产生名义成本，但这并不能完全消除偏见数据提交的风险。
因此，模型的选择及其训练方法变得至关重要，需要采用战略性的方法来接受和处理数据提交。系统设计者必须实施能够识别和缓解冗余或过于相似的数据条目影响的机制，以免影响数据集的多样性和代表性。为此，信息管理员（IM）有权拒绝过度重复先前提交数据的提交，确保模型能够持续接触到广泛的信息。
**防止资金被锁定：**本节讨论避免资金在智能合约中被“锁定”或“卡住”的方法。贡献者可能会遗漏收回退款，或者贡献者没有领取他们的存款部分，导致价值被“卡住”在合约中。为此，我们引入两个新参数：
• tc: 创作者必须等待的时间，以领取特定贡献的剩余退款（dr）。其中 tc > t。此外，这激励创作者部署模型，因为他们可能有机会索回一部分较大金额的存款（d）。合约可以规定这个时间远大于尝试退款的等待时间，以便给贡献者更多的时间收回存款，而不让创作者获取过多（tc ≥ t）。
• ta: 任何人必须等待的时间，以领取剩余退款（dr）。其中 ta ≥ tc > t，用于创作者未领取合约中“卡住”的价值的情况。
确实，可能还有更多变体，例如为已获得退款提交的贡献者引入一个值 td，其中 n(c) > 0，满足 ta ≥ td ≥ tc。
本节概述了防止资金在智能合约框架中变得不可访问或“被锁定”的策略。在某些情况下，贡献者可能会忽视领取他们的退款，或者未能索取他们指定的存款部分，导致资金在合约中未被索回。为了减轻这种情况，引入了两个新参数：
* **tc**：该参数指定创作者必须等待的时间，才能有资格索回特定贡献的剩余退款（dr）。这一条件确保创作者有动机去部署模型，因为如果贡献者未索回资金，他们有机会获得较大金额的退款（d）。建议合约规定 tc 的时间要远远超过退款尝试的最低等待时间，以便为贡献者提供充足的机会收回存款，同时限制创作者可以提取的金额（dr）。
* **ta**：该参数定义任何一方在索回剩余退款（dr）之前必须等待的时间。规定 ta ≥ tc 特别适用于创作者未能从合约中提取“卡住”的资金的情况。
此外，还可以考虑进一步调整这些参数，例如为已成功获得退款的贡献者引入的 td，其中 n(c) > 0。这些措施旨在确保资金在系统中流动自如，防止未被索回的资产在智能合约中积累，并促进动态的模型部署和优化过程。
在当今的数字生态系统中，终端用户设备（如智能手机、平板电脑和笔记本电脑）的计算能力仍然主要未得到充分利用，展现出未被完全挖掘的处理能力。在此框架内，用户通过在这些外围设备上执行去中心化应用程序（dApps）与网络互动。这种互动促进了网络中的数据验证，同时也为基础模型的迭代优化做出了贡献。此外，每个验证节点被分配一个信誉分数，该分数基于其历史上贡献的计算资源和参与网络的时间。信誉更高的节点会被委以更大的任务，相应地获得更丰厚的奖励。这一机制确保了任务和激励的优胜劣汰分配，加强了网络的完整性和效率。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.din.lol/din-cook-data-for-ai/chinese/din-cao-zuo-yu-jie-shao/comprehensive-network-architecture/exploring-din-an-in-depth-technical-overview/data-validation.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.