# WNS 开发对称会议

## 长期关注议题
- [ ] wns合约重要功能和特性列举：
- 域名限定字符集，排除零宽字符等不安全字符
- 可参考.bit现在使用的字符集
- 小萌：仅使用英文字母和数字
- tp：把字符集变成可配置项
- adu: .web3 顶级域仅支持英文字母和数字，次级域名由用户合约自行配置
- 域名注册支持跨链发送消息给wns链上合约或地址所在原生公链合约
- 用户注册手续费需收集到`Treasury`合约并向用户和`DAO`分红
- 交易版税：域名nft在二次市场交易时收取一定比例的版税
- 域名保留库
- 合理的设置最低续费期限：
- tp：现在ens支持最低续费期限为28天，但是有90天的保护期，最低续费期限应高于90天
- 小萌：还是按照传统域名最低续费一年？
- 域名nft metadata应该是一个随机生成的图像的ascii编码
- tp: metadata是一个ipfs的链接即可，可节省手续费
- 分批释放保留库域名，参考.bit，需要对保留库的域名有更加细粒度的控制
- [ ] wns合约开发里程碑
- [ ] 2022-12-31
- [ ] 各个模块合约功能开发完毕
- [ ] 合约集成
- [ ] 部署在本地的测试网
- [ ] 单元测试，集成测试，simulation
- [ ] 长沙团建

## 2023-03-06
- wns 架构
- 跨链did
- native did module
- 存储domain name metadata
- owner, resolver, ttl等
- 支持多级索引
- 点差：如adu.web3
- 范围查询和迭代：如所有以.web3为后缀的域名的查询和迭代
- key和value的序列化：
- key: suffix hash + label
- value: metadata {owner, resolver ,ttl}, proto3序列化方法
- 维护domain name唯一性
- tld 的注册，续费等逻辑
- 跨链逻辑
- gravity-bridge
- IBC
- evm 和 native did module的互操作性：
- stateful precompiles: https://github.com/evmos/ethermint/pull/1131
- evm hooks:
- 现有的ethermint已经支持
- 实现较简单
- 收取did发行年费：
- 定制化收取年费 vs 固定收取年费：
- [Track] 固定费用 + 竞拍？
- 固定费用不能价格发现
- 竞拍对于did发行商没有保障，可以根域到期后竞拍
- [Track] link：和azuki等nft ip的合作
- NFT社区合作方案：punk社区为例发行.punk（0.punk-9999.punk)0号nft持有人link可注册link.0.punk 交易给Tim Tim可注册Tim.0.punk (拥有过punk的凭证 ）
- tim：早期简单逻辑 + 后续升级
- 有限的根域 vs 无限的根域
- [Track] Tim：对did发行商的收益收取一定版税到社区金库
- smart contracts（ethereum等）
- 域名治理
- native did module + gov module
- 实现顶级域的投票注册等

## 2023-02-13
- 技术团队现状和规划
- 现状
- [ ] mvp第一阶段测试
- [x] 运维工具：https://github.com/wns-lab/pystarport
- [ ] 集成测试脚本：
- 参考 https://github.com/crypto-org-chain/cronos/tree/main/integration_tests
- [ ] gravity-bridge 和合约的对接
- 合约测试：
- [ ] hardhat框架
- [ ] 写成测试脚本
- 技术路线图：
- 实现一个前端可交互的mvp，包含我们承诺的核心特性，如跨链注册，其他did同步到witness等
- did的发行，注册
- 发行.web3并且开始用户邀请内测
- .web3的公开测试
- witness公开
- 技术团队角色和分工：
- 公链开发：adu,link
- 合约开发：tp
- 测试：adu,link,tp兼任
- 运维：adu,link,tp兼任
- 技术团队资源：
- 云服务器或者租vps服务器
- 从成本等角度考虑

## 2023-02-08
- Q&A
- 这条链是服务多个DID还是主打自己的DID？
- 怎么看未来did发展局势？是集中还是分散
- 跨链的具体架构和意义？用户将nft资产跨链是否那么刚需？（对于DID来说跨链的意义是什么？）
- 小萌：从用户角度 跨链的意义在于降低了注册门槛 他不需要对应链的代币就能注册 ，也增加了二级市场的流动性，从生态角度来看 是保证全链的共识统一，不会出现在不同链上一个did对应的是不同的人
- 项目到什么阶段？（技术和生态的合作）
- 除了顶级域名不冲突以外，我们认为DID间最基本的共识还有哪些？
- 小萌：DID未来和社交和在web3的信用凭证一定是强相关的，这就涉及到跨链操作性，整合全链数据，跨链，就是DID的第二大共识
- 怎么解决公链的流动性
- 对于在witness上发行的顶级域名及次级域名，是否可以收取类似版税这样的费用，可能是相对于web2的一个创新点，以及收益模型

- bp里需要补充跨链等方面的技术架构的内容

## 2023-02-06
- MVP 进度
- 基础框架搭建完毕，可编译运行，进入测试，迭代阶段
- 小萌：从MVP到最终成品的时间，人力等资源的安排
- 最快需要1-2两个月时间上线测试网，并公开试运营
- adu: 跨链注册以及did同步功能上线之后就可以开始试运营
- Tim:
- 先部署测试网，并在测试网上进行测试
- 功能迭代在测试网上发布
- link, tp:
- link熟悉main分支最新代码，并基于main分支做功能迭代开发
- tp测试合约功能，并与adu或者link对接完成gravity-bridge集成

- BP，官网进度
- 小萌：今晚最终版BP分享
- 小萌：官网已经搭建好了，解决证书问题
- Q&A
- [x] 代码是开源的 现在也有公链有自己的原生did 为什么选择witness公链发行did，和在cosmos上面发行did有什么不同
- 首先大部分公链上的原生did如ens, spaceid, aptname等一般来说不具备真实的跨链转移和互操作的能力，往往局限于某个区块链生态，也不兼容其他公链发行的did，他们可以为专属于该生态的应用提供服务，但无法兼顾大部分的web3使用场景
- cosmos生态里的公链大多是应用链，也就是说一条链就是一个应用，如果没有虚拟机的支持开发者很难在这条公链上发行did服务，即使是拥有虚拟机的应用链，如使用CosmWasm虚拟机的Osmosis，也将会因为和EVM不兼容导致开发者迁移成本很高，而少数兼容EVM的cosmos应用链如Evmos，Canto以及Cronos等，他们的现有的公链模块也不是服务于did产品，导致did发行商需要自己造轮子，并且局限于EVM的效率和成本问题，很难开发出能够落地的跨链did产品。其次这些did产品即使能够发布也很难兼容其他did产品，更别提多个did的治理了。本质上这些问题都是由于缺少公链层面的基础设施的支持，局限于EVM或其他虚拟机低下的效能和昂贵的成本。
- Witness是第一条cosmos did生态链，兼容EVM，熟悉solidity等语言的开发者可以很方便的将did应用迁移到Witness，开发成本低。其次Witness特有的基于IBC协议，gravity-bridge以及其他模块开发出的nameservice模块可以提供方便，廉价而且快速的基础的跨链DNS架构，同时我们将通过stateful precompiles技术打通EVM应用和公链基础设施的联系，充分为did应用赋能，而这既是其他公链的应用无法享受到的，也是cosmos生态现有的EVM兼容链所未能实现的。另外作为did生态链，我们将钱包应用，did服务以及社区用户这三者结合起来，形成完善的did治理机制，打通了从did发行商到终端应用，再到社区用户这一链条，让Witness上的did应用一旦获得承认就获得了来自应用场景和社区用户的共识，既服务于已发行的did应用，也服务于将来发行的did应用。最后Witness上的did应用可以流畅的兼容Witness平台上的其他did应用，让各个did应用真正的互通，为钱包等应用提供一站式的解析服务。
- Witness是cosmos生态第一条原生支持账户抽象相关标准的公链，不仅能够兼容多链公私钥账户交互，还能让did应用轻松实现用户使用任意token支付费用，甚至是手续费代付，或者自动定期扣款账户，社交恢复账户，免私钥密码登录账户等新一代的智能合约账户。让did应用能够开发出真正易用，功能丰富且兼顾用户自我主权的新一代did产品。
- [x] 什么是Witness
- Witness基于cosmos技术栈的，兼容EVM的一条did生态链。为did开发者提供did开发基础设施，为钱包应用，did应用和社区用户提供生态治理。
- [x] 为什么已经实现跨链的DID项目需要同步到WNS，同步的花费由谁承担？
- tp: 其他did应用同步到Witness上的的花费由did项目方承担
- 主动同步其他did到Witness上兼容开发的成本较高，较复杂，而且需要cpu,存储等资源的支持，费用应该由项目方来承担
- 对于ENS这样的有巨大知名度的did我们可以主动同步到Witness上，获取社区支持，费用由节点承担
- 小萌：
- 我们主动要同步过来的did由节点承担费用
- 其他did由项目方承担费用
- 旧的did项目同步到witness相当于在witness发行did
- [x] 如果发行did要经过社区投票治理，不是间接增加了发行商的发行成本，为什么发行商不自己选择别的公链发行
- 小萌：
- 发行的成本约等于市场运营的成本，在witness上发行能够精准的获取did社区用户，同时还获取了witness上的钱包应用的支持
- [x] DID发行商在WNS上发行的利益如何分配？大概发行成本是多少？
- 顶级域由did发行商控制，所有收益由did发行商所有
- 顶级域需要每年交年费，年费由链上或者其他方式治理
- did发行商越早在witness上注册顶级域，注册提案通过的可能性越高，话费越小，随着社区的壮大和有价值的顶级域逐年减少，越往后did发行商注册顶级域的成本越高，可能的年费也会越高
- [x] WNS能够为DID发行商提供多大程度的技术架构，有多少可拓展性和定制化选项？
- witness能够在常见的did的基础功能上为did提供真实的跨链流动性和跨链操作
- 域名拥有者可以控制该域名下所有的次级域名，包括注册，收益等
- did应用可完全定制域名的注册发行，收费等逻辑，Witness只提供了基础设施
- [x] 对于DID发行商的未来发展是否存在限制，例如上架钱包，修改规则等？
- 所有规则都基于开源开放的原则，规则的更改需要经过链上的投票治理
- witness上的did已经发行默认获得钱包应用和社区用户的支持，但是钱包应用和社区用户仍然有权利拒绝支持该did应用
- [x] 钱包如何参与DID的共同治理，不同体量的钱包的治理权限如何划分？
- adu:
- 钱包可以通过持有wns成为验证节点，并参与到投票
- 小萌：
- 除了钱包之外，社交平台对did的需求更高，如nostr
- web3信用平台，信用评级
- 钱包转账对id不敏感，社交用户对id更敏感
- [x] 接入WNS的钱包有哪些收益？（原本接入did会有他们自己的收入）
- 钱包作为验证节点享受出块收益和手续费收益
- 钱包作为大额票仓，在提案投票过程中可以享受到较大利益
- 钱包仍然可以与did应用商议额外的对接花费
- [x] 对于钱包合作的DID技术，是否有限制
- 没有限制
- [x] 为什么钱包选择与Witness合作而不是直接选择共识度高的DID合作？
- 选择witness就选择了很多原生跨链的did
- 钱包可以享受到生态发展，治理的收益
- witness聚集了did生态的共识，钱包可以享受到更大的流量
- [x] Witness是通过什么方式实现接入钱包后能在该钱包中显示和解析DID？
- 钱包等应用可以通过在前端调用sdk获取解析结果，
- 也可以将交易打包发送到链上后调用解析合约获取解析结果。

## 2023-01-31
- WNS 和 .bit 对比我们的区别和优势
- 小萌：
- 弱化我们在技术方面东西，和.bit是完全不同的项目，我们是公链，.bit是did应用
- 强调我们是公链平台
- 强调我们链上的应用和.bit的不同
- .web3和.bit的区别
- .web3的域名NFT天然具有跨链流动性
- witness可以解决后缀冲突的问题

- Tim:
-[Track](Creating note...) 其他did项目同步到witness的花费由谁承担
- .bit 怎么解决跨链流动性
-[Track] 怎么解决公链的流动性
- 讲清楚.web3
- 可能最大的客户不是.bit, 而是通过降低发行did发行门槛吸引来的did发行商
- 小萌：解决后缀冲突还是需要治理
- adu: 投票
- tp: 拍卖竞价
- 小萌：ICANN解决顶级域名的治理，结合投票和拍卖
- Tim: 不具备运营能力发行的域名可能会遭遇浪费，而且很难转移拥有者
- 如何吸引到强运营能力的团队发行顶级域名
- 投票的早鸟用户获得域名运营拍卖的收益奖励
- adu：witness把钱包等应用加入到生态的治理中，钱包可以投票决定要支持的did，did投票通过后也意味着获得了钱包等应用的支持，把did发行商，钱包和社区用户这三个重要的角色结合在一起。
- Tim:重要的是获取钱包等的支持
- 把wns和.web3分开谈
- web3域名的使用
- fomo：先到先得
- 社交属性
- 身份标识
- Tim: 总结成文档，和现有的did对比，弱化技术背景
- .web3: cosmos最大的did服务，不容错过
- witness:
- 服务于.bit，但目前还没有进驻
- 服务于新的did发行商
- 投资witness就相当于投资后续的新的did发行商，拿到did生态的门票，投资witness就相当于投资了web3时代的ICANN
- 创始团队将保持对witness的影响力
- 激起投资人的fomo情绪
- 小萌：版税等持续收入
-[Track] Tim: 对于在witness上发行的顶级域名及次级域名，是否可以收取类似版税这样的费用，可能是相对于web2的一个创新点，以及收益模型

## 2023-01-16
- [PR #3](https://github.com/wns-lab/wns-chain/pull/3/files) review
- 技术难点：
- ens: 钱包节点获取的ens解析记录有可能落后于最新区块
- tp: 转移时将解析记录置为空
- wns：跨链同步状态，两点链上的状态不一致的窗口期
- 教授：
- 应用观察两条链上的状态，只有当两边状态一致的时解析记录才有效
- 第三种状态不能从根本上解决问题，还是需要应用来杜绝作恶
- link：关系到使用场景，用特殊状态标记：冻结，并提醒用户
- adu: 考虑是否需要增加第三种状态：冻结
- 市场和商务下一步计划
- 小萌：
- 节后去和项目方接洽谈合作
- 出去之前基本工作完成：
- 官网bp
- mvp可运行
- github开源
- 项目背景资料分享给大家
- 教授：
- 可介绍媒体方面 coinlive的工作人员

## 2023-01-09
- wns [#PR 3](https://github.com/wns-lab/wns-chain/pull/3/files)
- 重构nameservice兼容cosmos-sdk v0.46
- 定义proto文件
- 利用proto生成基本数据类型和grpc service
- 集成gravity module
- 集成gov module
- link: 字符集验证patch push到link/wns-V0.0.1分支，adu基于此分支继续工作

## 2022-12-28
- nameservice 迭代：
- 存储状态：
- node -> record(resolver, owner, ttl)
- 可设计二级索引：node -> chainID -> record
- 字符集校验，在msg.ValidateBasic中设置：link
- gravity-bridge模块集成：adu
- x/gov简单的集成：adu
- evm，precomfiles：尽量推进
- 合约：
- 需要依赖evm和precompiles：
- 先熟悉研究，后续再推进：tp
- 如果短时间内precompile不成熟，现有nameservice已有注册功能

## 2022-12-12
- review 合约代码和wns-chain代码
- review nameservice 代码：
- 还需要msgServer, queryServer, keeper
- 周五review nameserver代码
- review 合约代码
- 已基本完成编译和调试
- 上周工作进度
- link：完成mini mvp：nameservice
- tp：合约代码的编译，调试测试功能
- adu：参与gravity-bridge风险模型评估：需要注意跨链的tokenmapping的管理，私钥使用kms管理，wns-chain使用cronos代码仓库
- 本周工作安排
- link：
- 周五一起review nameservice代码，并且把app跑起来
- tp：
- 择日review合约代码
- 准备registrar合约
- adu:
- 定义proto文件并生成数据结构

## 2022-12-05
- review pr: https://github.com/wns-lab/wns-chain/pull/2/files
- 本周工作安排：
- adu: 探讨gravity-bridge 集成，x/gov 域名治理集成
- link：完成wnskeeper和message server
- tp: witness链上需要有分配.web3域名的registrar合约和相应的价格预言机

## 2022-11-28
- wns-mvp 的路线图和里程碑
- https://hackmd.io/iOkOBVfpR5ukFub5bujiAQ

- 同步上周工作内容和当前工作内容
- adu: 新提交一个pr初始化`x/wns`的类型和数据结构：https://github.com/wns-lab/wns-chain/pull/2
- tp: 集成gravity，权限控制，删除不需要的功能
- link：mini-mvp 模版和了解ethermint

## 2022-11-14
- 本周周五共同review合约代码，结束第一阶段合约代码开发
- gravity -> controller -> registrar -> registry

## 2022-11-21
- 合约开发经验：
- 剥离了erc721和erc1155模块，保留registry和resolver，控制器以及gravity。控制器控制注册流程，控制器由gravity直接控制
- tp: 收尾工作和单元测试
- mvp开发
- 路线图和里程碑
- adu：输出路线图和里程碑，知道mvp包含的特性
- cosmos端开发
- fork ethermint
- module 开发
- 测试
- mini版mvp
- link：输出方案
- gravity集成

## 2022-11-07
- [ ] 合约开发进度和细节同步
- gravity 集成：https://github.com/wns-lab/wns-contracts/pull/12/files
- 控制器合约，注册商合约（ERC721）, 注册局合约
- 2022-11-17 合约部分基本完毕，有一些简单的单元测试

## 2022-10-31
- [x] 合约架构调整
- WNSRegistry 继承 ENSRegistry
- WNSRegistrar 继承 ERC721， IBaseRegistrar， Ownable
- WNSRegistrarController 继承IETHRegistrarController， Gravity(某个实现跨链功能的合约，delegatecall方便升级)
- PublicResolver?

- ERC4377现在还在研究阶段，后面再考虑实现

## 2022-10-24
- [ ] 合约开发经验总结
- 要在`controller`合约做控制，包括是否为保留域名，是否为合法字符，包括ERC1155封装等
- 继承`ENSRegistrarController`合约？tp：重写控制器合约。
- `ENSRegistry`，`PublicResolver`合约可以继承后override相关函数。
- 保留库合约可以设置解锁全部保留域名的期限，tp: 可以硬编码到合约里
- controller合约可以继承保留库合约：避免额外部署保留库合约
- 设计好合约的状态变量，以及变量的可见性，以及合约方法的可见性
- 尽量通过集成openzeppelin的库合约的方式实现功能特性
- 保留库域名名单什么时候确定？
- 小萌：分批释放保留库域名，参考.bit，需要对保留库的域名有更加细粒度的控制
- 上线时确定
- 保留库的拍卖功能：
- 小萌：拍卖成功后所属权鉴权
- tp：拍卖的时候提交地址确保谁出钱谁拥有
- [track] 拍卖功能：链上链下？
- [track] ens的价格拍卖功能怎么实现的？

## 2022-10-17
- [x] 讨论wns合约开发roadmap：
- 根据产品需求通过修改或添加合约实现相应的功能特性：https://github.com/wns-lab/wns-contracts/issues/7
- deadline: 2022-11-17
- wns合约集成测试
- 可能的wns合约重构和测试

## 2022-10-10

- [x] wns合约线上协作开发工具和流程
- 开发工作内容包括代码和文档等，开发组通过github进行协作开发，开发人员需通过提交github pull request的方式提交工作内容，参与review，并最终merge到wns的合约开发仓库：https://github.com/wns-lab/wns-contracts
- 开发进度通过github issue, milestone等管理
- hackmd以及google doc用于线上文档协作，可共同编辑，评论等，技术文档推荐使用hackmd，方便使用markdown并同步到github
- 每周一次的技术同步会议，可通过线上google meet等方式或线下进行

- [x] 基金会头像
- [x] 已有素材，挑选完毕即可使用