知县:UniPass 与它的 Web 3.0 大规模应用愿景
播客音频: EP.38 [CN] - Frank Lou: Unipass and its Vision for Web 3.0 Mass Adoption / 知县:Unipass 与它的Web 3.0 大规模应用愿景Multicoin Capital 旗下的播客节目「伍拾壹说(51%)」,第 38 期访谈了雷兔科技(Lay2 Tech)创始人知县。 在这一期的播客节目中,知县介绍了 Lay2 团队的背景,UniPass 产品的构思,解释了 UniPass 的安全性和私钥存储解决方案,讨论了 Web 3.0 中的身份、链上信誉,最后还谈到了以去中心化方式运营团队的经验。 以下是这期播客节目的文字稿,全文将近 2 万字,干货满满,建议先点赞收藏再阅读 !目录创业经历 2「雷兔」的由来从 Portal Wallet 到 UniPass为何选择 Nervos?Nervos 的灵活性UniPass 如何降低 Web 3.0 的门槛?UniPass 的使用场景UniPass 的安全性用户链上身份和信誉分布式办公1、创业经历主持人: 大家好,欢迎来到最新一期的 51 说,我是主持人 Mab...

Space 回顾|市场不作美?BTC 生态该如何绝处逢生
8 月 6 日,CKB 中文举办了话题为 “市场不作美?BTC 生态该如何绝处逢生” 的 Space,邀请到了 Seal 社区的 builder 汉堡,Stable++ 的 Community Lead Adam Lee,Pizza 的 builder 唐长老,木偶中文的 Shaqima,Ordinals 的 builder Kumi,以及 DotSwap 的联合创始人兼 CEO 泽明。 这场 Space 一共持续了将近 2 小时,欢迎还没有来得及收听的小伙伴有空时收听音频回放:https://x.com/CKB_CN/status/1820790395045081401 以下是根据音频回放整理的部分嘉宾分享的部分重点内容(全文约 8000 字,建议先收藏再阅读):1主持人:我们看到在这次大跌中,比特币作为共识最强的区块链,显现出了行业王者的地位,价格相对其他币种也算扛跌。对于比特币生态来说,各位嘉宾认为它是否承接住了这种相对稳定性?比特币生态目前处于什么阶段?相较于 Solana 和 Torn 生态,它的生态龙头地位在社区里是否达成共识? 泽明:关于比特币,我个人并不特别看好。...

深入了解 EOA、CA、智能合约钱包的区别
接上文:「钱包」不是个好类比,拆分 3 层重新理解 以下内容整理自「Web3 101」播客的第 S1E14 期,主播为阿伟(Awaei),嘉宾为 UniPass 创始人知县。阿伟(主持人):其实钱包也有一个不断变化的过程,刚才你提到了 EOA,后面我们还会提到更多的钱包概念。你能不能给我们的听众讲一讲钱包的整个发展过程,优势以及发展动力? 知县(UniPass 创始人):钱包相关的概念很多,也很复杂,我专门写过一篇科普文章《Web3 账户概念梳理,钱包使用不迷路》。 EOA,是 Externally Owned Accounts 的缩写,中文叫外部账户,是以太坊或者说 EVM 链的一个独有概念。以太坊地址是由公钥直接计算变换得到的,就是我刚才背的那一段,它没有任何内部结构。EOA 生成的时候不依赖于区块链本身,跟以太坊没有关系,所以它叫外部账户,在外部生成并且控制的账户,也是我们平时用的最多的账户。 MetaMask 生成的钱包账户是 EOA,最近大家常说的 MPC 生成的也是 EOA。从区块链的角度来看,EOA 的功能更像是个触发器,因为绝大多数业务逻辑其实是在链上的合约内部完...
<100 subscribers
知县:UniPass 与它的 Web 3.0 大规模应用愿景
播客音频: EP.38 [CN] - Frank Lou: Unipass and its Vision for Web 3.0 Mass Adoption / 知县:Unipass 与它的Web 3.0 大规模应用愿景Multicoin Capital 旗下的播客节目「伍拾壹说(51%)」,第 38 期访谈了雷兔科技(Lay2 Tech)创始人知县。 在这一期的播客节目中,知县介绍了 Lay2 团队的背景,UniPass 产品的构思,解释了 UniPass 的安全性和私钥存储解决方案,讨论了 Web 3.0 中的身份、链上信誉,最后还谈到了以去中心化方式运营团队的经验。 以下是这期播客节目的文字稿,全文将近 2 万字,干货满满,建议先点赞收藏再阅读 !目录创业经历 2「雷兔」的由来从 Portal Wallet 到 UniPass为何选择 Nervos?Nervos 的灵活性UniPass 如何降低 Web 3.0 的门槛?UniPass 的使用场景UniPass 的安全性用户链上身份和信誉分布式办公1、创业经历主持人: 大家好,欢迎来到最新一期的 51 说,我是主持人 Mab...

Space 回顾|市场不作美?BTC 生态该如何绝处逢生
8 月 6 日,CKB 中文举办了话题为 “市场不作美?BTC 生态该如何绝处逢生” 的 Space,邀请到了 Seal 社区的 builder 汉堡,Stable++ 的 Community Lead Adam Lee,Pizza 的 builder 唐长老,木偶中文的 Shaqima,Ordinals 的 builder Kumi,以及 DotSwap 的联合创始人兼 CEO 泽明。 这场 Space 一共持续了将近 2 小时,欢迎还没有来得及收听的小伙伴有空时收听音频回放:https://x.com/CKB_CN/status/1820790395045081401 以下是根据音频回放整理的部分嘉宾分享的部分重点内容(全文约 8000 字,建议先收藏再阅读):1主持人:我们看到在这次大跌中,比特币作为共识最强的区块链,显现出了行业王者的地位,价格相对其他币种也算扛跌。对于比特币生态来说,各位嘉宾认为它是否承接住了这种相对稳定性?比特币生态目前处于什么阶段?相较于 Solana 和 Torn 生态,它的生态龙头地位在社区里是否达成共识? 泽明:关于比特币,我个人并不特别看好。...

深入了解 EOA、CA、智能合约钱包的区别
接上文:「钱包」不是个好类比,拆分 3 层重新理解 以下内容整理自「Web3 101」播客的第 S1E14 期,主播为阿伟(Awaei),嘉宾为 UniPass 创始人知县。阿伟(主持人):其实钱包也有一个不断变化的过程,刚才你提到了 EOA,后面我们还会提到更多的钱包概念。你能不能给我们的听众讲一讲钱包的整个发展过程,优势以及发展动力? 知县(UniPass 创始人):钱包相关的概念很多,也很复杂,我专门写过一篇科普文章《Web3 账户概念梳理,钱包使用不迷路》。 EOA,是 Externally Owned Accounts 的缩写,中文叫外部账户,是以太坊或者说 EVM 链的一个独有概念。以太坊地址是由公钥直接计算变换得到的,就是我刚才背的那一段,它没有任何内部结构。EOA 生成的时候不依赖于区块链本身,跟以太坊没有关系,所以它叫外部账户,在外部生成并且控制的账户,也是我们平时用的最多的账户。 MetaMask 生成的钱包账户是 EOA,最近大家常说的 MPC 生成的也是 EOA。从区块链的角度来看,EOA 的功能更像是个触发器,因为绝大多数业务逻辑其实是在链上的合约内部完...
Share Dialog
Share Dialog
Nervos 基金会致力于创建一个透明、去中心化和社区深度参与的平台,因此 Nervos Nerwork 的技术是并且永远是开源的。这也适用于 Nervos 未来的决策。在这篇文章中,你将了解你或者其他任何人如何通过 Nervos RFC 发表意见或建议,从而在影响 Nervos Network 的技术方向方面发挥作用。
如果你想影响 Nervos Layer 1 协议的技术决策,首先需要创建一个可公开访问的文档,称为 RFC(Request for Comments,意见征求)。
我们欢迎社区的小伙伴们为知名的 RFC 做出贡献,让 Nervos Layer 1 朝着更好的方向升级迭代。今年 5 月的主网升级,实际上就是从 RFC 提案开始的,这些提案公开征求社区的反馈意见,帮助 Nervos Layer 1 更好地完成了升级。
举个例子,RFC37 – CKB Consensus Change(CKB2021 版)详细说明了对 Layer 1 协议升级的相关变更。点此查看该具体文档的添加位置以及收集到的反馈意见。RFC37 链接到其他 RFC,这些 RFC 共同构成了 RFC 集合,详细说明了协议升级所需的所有变更。
未来的所有硬分叉升级和软分叉升级,也将从可公开访问的 RFC 提案开始,我们期待你做出贡献并提出改进意见。
下面,我们回到 RFC 的基本介绍和相关操作上。
Nervos Network 由一系列协议和创新方法组成。关键协议的设计和实现需要有明确的文档和技术规范,这一点至关重要,因此我们采用 RFC 流程。RFC 是 Request for Comments(意见征求) 的缩写,提交 RFC 也是 Nervos 社区方案实施的第一步。
以下是部分案例:
现有 RFC 的完整列表:https://github.com/nervosnetwork/rfcs/blob/master/README.md
最简单的参与方式,是通过提供反馈为现有的 RFC 做出贡献。你的贡献包括但不限于:修改错别字,提出问题,建议对文件进行重大的结构性修改,提供代码实例,等等。
打开 Nervos RFC 列表,找到处于 Draft 或 Proposal 状态的 RFC。选择其中一个,通读一遍,看看你是否能为讨论添加一些东西。如果你在 readme 文件中找不到 RFC,可以随时浏览 Issues 和 Pull requests。你也可以向它们添加反馈。
你对 RFC 的贡献没有任何限制,任何贡献都不会太小。选择一些你在阅读本文时感到舒服的东西,当你更有信心时,你可以扩大规模。
如果你想在 Nervos RFC 中添加内容,只需要拥有一个 GitHub 账号即可。GitHub 的账户创建是免费的,我们鼓励你创建一个。
技术讨论通常从其他地方开始,例如从 Nervos Talk 论坛的「CKB 开发和技术讨论」板块开始。如果你想参与其中,那么你也只需创建一个免费的账户。
创建新的 RFC 可能要比为现有的 RFC 做贡献付出更多的努力。Nervos 基金会开发者关系团队的 Jordan Mack 为你准备了一些技巧,以最大限度地提高你的 RFC 成功率:
开始与社区非正式地讨论你的内容,以获得早期反馈。在 Discord 和 Telegram 上与他人交谈是不错的起点。 一般来说,Nervos Discord 上的 #dev-chat 频道是进行技术讨论的好地方。
对你的提案进行详尽的记录。这应该足够详细,以便每个人都可以准确地了解提案的内容、提案的原因以及如何实施的确切技术细节。将你的文章公开发布到可以查看的地方,并开始正式收集其他开发人员和用户的反馈。发布到 Nervos Talk 论坛的「CKB 开发与技术讨论」板块,就是个不错的选择,因为这是 Nervos 技术社区的常规互动场所。正式的反馈收集也很重要,可以在后面的步骤中突出社区的观点。链接到以前的讨论或引用可能是对 RFC 有价值的补充(只需将其发布在评论中,而不是作为 RFC 的一部分)。
一旦你收集了反馈并吸引了社区的支持,请完善你的提案并制定正式的 RFC。 请务必使用 Nervos Network RFC README 中的指南。在 GitHub 中的 Nervos Network RFC 库添加 pull request。
你的提案经过审查和合并后,如果它属于信息提案,它会被标记为 Draft;如果是标准提案,则标记为 Proposal。此时,你的提案将接受 Nervos 社区和利益相关者的审查。RFC 的接受是基于粗略共识规则(rough consensus),这意味着 Nervos 基金会已确定该提案已经过审查并获得了社区和利息相关者的大量支持。未来,RFC 的接受将通过去中心化治理的方式来处理,可能会使用 DAO 投票。
RFC 的接受过程可能需要几个月到几年的时间,因为你的提案必须经过社区大量人员的审查,但任何人都没有义务快速跟进,或者根本没有义务要这样做。所以,你要有耐心,但也不要害怕继续在社区内宣传你的提案,以获得更多的支持和关注。那些能从你的提案中获益的人更有可能审查和支持你的提案,而他们只有在知道你的提案存在时才会进行审查。
5. 在你的提案被接受后,它将成为一个标准,成为 Nervos Network RFC 库中的一部分。然而,一个标准的好坏很大程度上取决于使用它的项目。因此,你应该继续推广和鼓励其他人使用该标准,直到它在生态系统中稳固了自己的地位。
无论你是选择对现有的 RFC 做出贡献,还是创建你自己的 RFC,或者仅仅是观察协议的进展情况,你都是社区的一员。对此,我们很高兴。
最后,希望大家持续参与,积极为 Nervos 平台的未来提意见和建议,就像这次社区为帮助 Nervos Layer 1 主网升级所做的那样。
Nervos 基金会致力于创建一个透明、去中心化和社区深度参与的平台,因此 Nervos Nerwork 的技术是并且永远是开源的。这也适用于 Nervos 未来的决策。在这篇文章中,你将了解你或者其他任何人如何通过 Nervos RFC 发表意见或建议,从而在影响 Nervos Network 的技术方向方面发挥作用。
如果你想影响 Nervos Layer 1 协议的技术决策,首先需要创建一个可公开访问的文档,称为 RFC(Request for Comments,意见征求)。
我们欢迎社区的小伙伴们为知名的 RFC 做出贡献,让 Nervos Layer 1 朝着更好的方向升级迭代。今年 5 月的主网升级,实际上就是从 RFC 提案开始的,这些提案公开征求社区的反馈意见,帮助 Nervos Layer 1 更好地完成了升级。
举个例子,RFC37 – CKB Consensus Change(CKB2021 版)详细说明了对 Layer 1 协议升级的相关变更。点此查看该具体文档的添加位置以及收集到的反馈意见。RFC37 链接到其他 RFC,这些 RFC 共同构成了 RFC 集合,详细说明了协议升级所需的所有变更。
未来的所有硬分叉升级和软分叉升级,也将从可公开访问的 RFC 提案开始,我们期待你做出贡献并提出改进意见。
下面,我们回到 RFC 的基本介绍和相关操作上。
Nervos Network 由一系列协议和创新方法组成。关键协议的设计和实现需要有明确的文档和技术规范,这一点至关重要,因此我们采用 RFC 流程。RFC 是 Request for Comments(意见征求) 的缩写,提交 RFC 也是 Nervos 社区方案实施的第一步。
以下是部分案例:
现有 RFC 的完整列表:https://github.com/nervosnetwork/rfcs/blob/master/README.md
最简单的参与方式,是通过提供反馈为现有的 RFC 做出贡献。你的贡献包括但不限于:修改错别字,提出问题,建议对文件进行重大的结构性修改,提供代码实例,等等。
打开 Nervos RFC 列表,找到处于 Draft 或 Proposal 状态的 RFC。选择其中一个,通读一遍,看看你是否能为讨论添加一些东西。如果你在 readme 文件中找不到 RFC,可以随时浏览 Issues 和 Pull requests。你也可以向它们添加反馈。
你对 RFC 的贡献没有任何限制,任何贡献都不会太小。选择一些你在阅读本文时感到舒服的东西,当你更有信心时,你可以扩大规模。
如果你想在 Nervos RFC 中添加内容,只需要拥有一个 GitHub 账号即可。GitHub 的账户创建是免费的,我们鼓励你创建一个。
技术讨论通常从其他地方开始,例如从 Nervos Talk 论坛的「CKB 开发和技术讨论」板块开始。如果你想参与其中,那么你也只需创建一个免费的账户。
创建新的 RFC 可能要比为现有的 RFC 做贡献付出更多的努力。Nervos 基金会开发者关系团队的 Jordan Mack 为你准备了一些技巧,以最大限度地提高你的 RFC 成功率:
开始与社区非正式地讨论你的内容,以获得早期反馈。在 Discord 和 Telegram 上与他人交谈是不错的起点。 一般来说,Nervos Discord 上的 #dev-chat 频道是进行技术讨论的好地方。
对你的提案进行详尽的记录。这应该足够详细,以便每个人都可以准确地了解提案的内容、提案的原因以及如何实施的确切技术细节。将你的文章公开发布到可以查看的地方,并开始正式收集其他开发人员和用户的反馈。发布到 Nervos Talk 论坛的「CKB 开发与技术讨论」板块,就是个不错的选择,因为这是 Nervos 技术社区的常规互动场所。正式的反馈收集也很重要,可以在后面的步骤中突出社区的观点。链接到以前的讨论或引用可能是对 RFC 有价值的补充(只需将其发布在评论中,而不是作为 RFC 的一部分)。
一旦你收集了反馈并吸引了社区的支持,请完善你的提案并制定正式的 RFC。 请务必使用 Nervos Network RFC README 中的指南。在 GitHub 中的 Nervos Network RFC 库添加 pull request。
你的提案经过审查和合并后,如果它属于信息提案,它会被标记为 Draft;如果是标准提案,则标记为 Proposal。此时,你的提案将接受 Nervos 社区和利益相关者的审查。RFC 的接受是基于粗略共识规则(rough consensus),这意味着 Nervos 基金会已确定该提案已经过审查并获得了社区和利息相关者的大量支持。未来,RFC 的接受将通过去中心化治理的方式来处理,可能会使用 DAO 投票。
RFC 的接受过程可能需要几个月到几年的时间,因为你的提案必须经过社区大量人员的审查,但任何人都没有义务快速跟进,或者根本没有义务要这样做。所以,你要有耐心,但也不要害怕继续在社区内宣传你的提案,以获得更多的支持和关注。那些能从你的提案中获益的人更有可能审查和支持你的提案,而他们只有在知道你的提案存在时才会进行审查。
5. 在你的提案被接受后,它将成为一个标准,成为 Nervos Network RFC 库中的一部分。然而,一个标准的好坏很大程度上取决于使用它的项目。因此,你应该继续推广和鼓励其他人使用该标准,直到它在生态系统中稳固了自己的地位。
无论你是选择对现有的 RFC 做出贡献,还是创建你自己的 RFC,或者仅仅是观察协议的进展情况,你都是社区的一员。对此,我们很高兴。
最后,希望大家持续参与,积极为 Nervos 平台的未来提意见和建议,就像这次社区为帮助 Nervos Layer 1 主网升级所做的那样。
No comments yet