yes3 是一个 protocol。yes3 也指代该protocol 的极简 web 前端（用以展示 yes3 protocol 的可能性）. yes3 现在的功能非常简单, A 问B 一个问题, B 可以回答 是 否 或者 不知道. 该回答会以 SBT 的形式被记录在链. https://ethglobal.com/showcase/yes3-qwjop 是一个简易的前端的演示视频.

For English Readers, please check out the older version at bit.ly/yes3app

微信直接点开的没有排版, 建议复制到浏览器查看.

yes3 的长远价值

模糊信息上链

模糊信息

在区块链语境下, 信息大致有四种, 线上清晰信息, 线上模糊信息, 实体世界清晰信息, 实体世界模糊信息.

其中清晰信息的上链通常比较容易, 不论是线上清晰信息, 比如某网站的访问量, 还是实体世界清晰信息如足球比赛比分, 天气温度, 都可以通过目前的典型预言机上链.

而模糊信息的上链则更为复杂, 比如线上和人语音开会觉得对方的观点很有价值, 或者实体世界踢球觉得对手踢的不错.

yes3 是关于模糊信息的共识上链的一种手段, 以提问者作为上链动作的发起者(也是需求者), 以问答的形式获得双方共识, 从而让模糊信息获得基于至少两个人共识的见证 (attestation). 比如我可问你「刚才吃饭中, 我提到 NLP 可以作为一种新的 UX 这个观点, 你是否觉得有道理?」你如果回答 yes. 那么我们关于这个对话, 一条在实体世界的模糊信息的共识, 便上链了.

模糊信息上链的种种价值，还有待挖掘(*有待在后续版本补充*)，这里指出其中一个抽象价值，如同网络国家中所说, 作为不可篡改历史, 可以给与所有人公平的权力去叙述历史.

双人共识 作为 弱见证的组件 以 提供基本可信度

这里需要强调一点: 本质上, 通过 yes3上链的是共识, 而不是信息和事件本身. 共识未必符合事件实际的情况. 如果想让二者统一, 如果想知道链下真的发生了什么, 则需要额外的激励机制 和信用机制. 这些机制将不会在yes3 protocol 中实现. yes3只是一个共识层, 不对信息的真伪做判断. 在链上信用机制整体更加成熟的未来, 我们希望开发基于yes3 数据的激励层和信用层protocol, 来去发现事件的真伪.

由于缺乏激励和信用, yes3 只可以说对事件进行了弱见证. 当然, 弱见证在很多情况下也是相对可信, 值得参考的, 就好像人们会相信大部分朋友发的朋友圈分享是大致真实的. yes3 由于是基于 2 人共识的见证, 在其他条件一致的情况下, 其可信度应该高于朋友圈, 微博, 等单人表达. 比如, A 一条 pyq 说 「我和 B 喝酒 ，把 B 喝倒了」， 其可信度低于 如下问答：A 问「今天我们喝酒，你是不是倒了」， B 回答是。

yes3 选择双人共识作为基本单位。首先，部分信息类型，包括但不限于关系型，私下互动型，双人共识已经有实际上值得参考的可信度，如前例所示。其次，对需要更多人共识的场景，也可以抽象为双人共识的组合。例如，A 可将问题「我今日在上海新天地穿azuki的帽衫跳了一段街舞，是否？」问 B，C，D等几个人，通过获得多个「是」，来去增加该信息的可信度，如果B，C，D等人是 azuki 的holder， 或者运营团队，则他们的「是」会更加可信。

信任的来源和传递

虽然 yes3 并不会有独立的信任机制（比如一个信用分数），但 yes3 所产生的问答，如前例所示，也拥有一些可信度。究其原因：在网络上, 有些人已经拥有了声誉。

声誉的来源可能很多, 比如ta是你现实中认识的朋友，或者线上合作过项目的队友，比如ta 的github 上有个 5000 个 star 的项目, 比如ta 作为 CEO 运营一家世界五百强公司, 比如 ta 发起了以太坊项目, 比如ta 写了几篇爆款文章, 比如ta钱包里有 500E, 以及等值的 NFT. 你可以通过一些证据, 来去判断/验证 ta 的声誉.

yes3 本身不生产声誉， yes3是声誉的搬运工，是一种声誉的流动和传递机制. 比如当我问一个 5000 star github 核心贡献者, 「我于 2023 年 1 月 23 日发现的用户资产可能被错误授权的bug 是否有价值.」 他回答 yes. 那么他的声誉就相当于有一部分流动到了我身上. 其他人就可以通过确认这个核心贡献者的声誉, 来认可我对该项目的贡献. 这样声誉的的传递可以不只是一度的, 我还可以通过回答其他人的问题, 来进一步传递声誉.

有语义的关系

传统的web 社交关系局限于几种：关注，好友，点赞，etc. 关系本身是同质化的，不带语境的。在这类社交图谱中，我们通常无法知道两个人的关系究竟意味着什么，他们是经常一起吃饭，还是工作伙伴，抑或者是共同好友介绍认识？ 经 yes3 的问答产生的关系是有语义的，带有语境的。比如，A问「你读完我关于 HK mplus sigg特展的 文章，是否对中国当代艺术产生了更多的兴趣？」。B回答 yes。 那么A和B的这个关系就是一种读者和作者之间的关系，语境是 sigg 特展。

这个特性带来一些有趣的可能性。比如，借助自然语言处理，我们可以选取语义类似的关系，组成一张有主题的社交关系网络。比如可能一张由食物链接的社交网络，或者一张由Nike产品链接的社交网络。有语义的社交关系也可以帮助用户更好的去探索自己的弱联系，通过阅读一些自己不熟的朋友（或者只是二度关系的存在）和他们社交网络中的其他人的关系语义，尤其是和自己熟悉的朋友的关系语义，用户可以更好的理解自己的弱关系，从而更好的与之互动。

围绕创作者的关系

在拥有 基本可信度 以及 语义的关系的前提下，有一类关系值得单独阐述，即围绕着创作者的关系。读者和作者的关系有一个天然的语境，即作品。yes3可以非常自然的帮助创作者记录这种关系。比如，A 问「你否觉得 我在 以太坊2023路线图解析 中对splurge的解释清晰易懂，新手友好？」然后几位以太坊基金会核心贡献者B，C，D回答了「是」。

该记录对创作者的声誉有独特意义，以前创作者的声誉主要标准是阅读量，粉丝数。yes3 让作者通过为自己的作品寻求专业人士的特定认可，从而建立自己的声誉。该记录也可能拓宽内容策展的方法；比如一个平台可以决定展示所有 被超过 3 个以太坊基金会成员认可的，内容关于以太坊的，新手友好的 作品。这里后两个标签都可用自然语言算法从问题描述中推断，而第一个标签则可以通过其他链上身份dapp获得。

对有特别细致需求的策展人，也可以自己提前设置一些问题，让创作者拿这些问题去问特定群体读者，然后根据回答情况来决定如何策展。比如vitaDAO 可以 设置问题 「你认为这篇文章中提到的抗衰老的生物学原理的是否可靠（有知名期刊论文实验的支持）？」，同时设置有效回答者为vitaDAO 中一些有至少生物本科背景的成员。然后让创作者们可以拿自己的作品和这些成员寻求认证，当某个作品获得超过5个yes之后，则自动提醒vitaDAO某策展人去人工审核该作品。

潜在产品形式

这里给出一种潜在产品形式的假想设计，可以如同0xEcho在mirror里嵌入评论区一样，在mirror文章中嵌入回答问题的按钮，只需要钱包登录，即可在mirror界面一键回答问题并签名。

社群关系的分级

还有一类关系值得单独阐述, 即社区边界附近的模糊关系. 这里的关键是, 社区边界附近, 比如并非 nouns holder 但是为 nouns 社区贡献过的成员, 比如并非正式被以太坊基金会雇佣, 但是协助以太坊基金会成员推进项目的成员. 社区内部的事务, 关系也好, 信任也好, 见证也好, 其实有很多 DAO tools 可以解决; 比如用来集体决策的 snapshot, 用来认证成就的 otterspace 等. 但是在社区边界上, 很多时候没有好的链上共识传递机制,和关系的记录机制.

以 nouns 社区举例, nouns 中文社区生态具体是由谁建立的, 谁应该获得 nouns 金库的奖励, 这个事情的追溯是困难的, 混乱的. 中文社区整个建立过程和英文社区相对独立, 其关系和共识不会自动的转到英文社区, 而需要借助某种媒介. yes3 因为不强求中心化的配置, 所以很适合在这个阶段使用. 每个成员去说服一个新成员加入的时候, 都可以问这个新成员「你是否被我带进 nouns 中文社区?」. 通过这个问题, nouns 英文社区就可以更好的理解中文社区的共识和关系, 从而进行清晰的追溯.

再以 azuki 社区举例, 社区会组织给 holder 的线下活动, 不过线下活动另一个重要作用也许是吸引潜在买家, 让他们更了解 azuki 文化从而真的去购买 azuki. 如何去筛选可靠的潜在买家呢, 比如真的热爱 azuki 文化的人 而不是 纯粹的投机者? 他们是一个 nft 社区的边界. yes3 适合在这个情境使用, azuki 社区可以设置一些问题, 比如「我是否为 azuki CN gitbook 做了很多贡献? 」「我是否在某次 azuki 线下活动帮助邀请了一位 dj?」 等等. 然后社区可以设置一些机制, 比如任何非 azuki holder 如果在这些问题上获得超过3 个 azuki holder 的回答的 yes. 那么久可以获得一些社区的权益, 或者某次闭门活动的 pass. 这个方式允许社区更灵活的去促进社区边界的关系, 也引导 nft holder 去以简单轻量的方式帮助社区拓展这个边界.

其他可能性

有待在未来的版本中完善: 海龟汤, computation with human in the loop, on-chain gaming integration.

项目定位

yes3 是一个 开源的 公共的 项目.一个protocol. 一个hyperstructure .

作为一个开源项目, yes3 除了开源包括前端代码在内的的所有代码; 还会追求 build in public, 开放所有的产品/开发会议, 开放所有的产品/开发文档.

作为一个公共项目, yes3 不追求最大化捕获商业价值, 但是仍然拥有相应的治理机制去获得建设和维护所必要的资金, 以及激励相应的贡献者.

作为一个 protocol, yes3 记录 所有 回答 yes的 场景到链上. 根据具体的需求, 会有不同的 app, 比如 request for endorsement, request for promise, creator-reader interaction, opinion pooling, human oracle etc. 根据具体的场景，会有不同的UI/UX，比如 yes3 farcaster integration, yes3 link3 integration, yes3 mirror addon, yes3 discord bot, yes3 TG bot, etc. yes3 在 protocol 层面会不断开发功能来便利 app 的开发者, 比如 ZK permission management, programmable gating, customizable query, etc. yes3 追求极致的可互操作性，yes3 产生的 SBT 是互操作的媒介。 yes3 创造的是通用的类型, 由用户和具体产品开发者来创造具体的实例.

作为一个 hyperstructure, yes3 追求即使在无人值守的情况下, 永久的运行在链上的能力.

治理

具体的 governance 机制仍然有待设计, 不过以下是一些设计参考的原则.

1 内容管理由一个 DAO 完成, 并获得某种相应激励.

2 核心 protocol 开发和设计决策(代码管理)在早期会以比较 centralized 的方式进行(但仍然是完全开放的), 在 protocol 进入稳定期之后, 早期核心团队交出修改代码的权力到某种治理机制下.

3 yes3 app 生态会以 decentralized 的方式开始, 任何开发者都可以 permissionless 的基于 yes3 protocol 进行开发. protocol 核心团队也会开发一些 app, 来冷启动整个生态以及展示 yes3 protocol 的潜在用法. 基于 yes3 的 app 可以是商业产品.

4 应该有某种tokenomics 来激励投资人和贡献者, 以及作为protocol 稳定期治理机制的一部分.

roadmap ( very tentative)

1 上线 主网目前的简陋版本 作为 alpha test.

2 设计初步的 tokenomics 和 治理机制.

3 开发 yes3 正式版 v1.

3.1 应当把相应的 代币和治理的接口留出

3.2 支持从 yes3 alpha 版本导入数据.

3.3 使用 ZK 支持 SBT 展示的权限控制

3.4 使用 off chain LLM 来协助合并相同问题

3.5 支持检索问题

3.6 支持按照 问答 SBT 拥有情况去检索符合条件的用户.

3.7 支持多选题

3.8 设计一个问题 NFT 管理页面, 包括设计 NFT owner 对 问答 SBT 的影响方式.

3.9 实现一个 SBT flow graph visualization

4 基于 yes3 正式版开发 app/插件

• 在farcaster, lenster, twitter 中获得 yes

• 在 mirror, paragraph, matters 中获得 yes

• 在 web3 profile page 自定义 SBT 的展示, 以及获得 yes

• 在 discord , telegram 中获得 yes3

• 通过和社群核心成员获得特定问题的 yes 成为社群的一员