知县: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 Blog;原文链接:Virtual Machine Improvements
与 Nervos CKB 主网升级一起推出的还有 CKB-VM v1,它是可以在 Nervos Layer 1 上使用的虚拟机。这个新版本的 CKB-VM 提高了智能合约的执行效率,并增加了一些新功能供开发者在开发智能合约时使用。
同时,为了向后兼容,CKB-VM v0 仍然可用,开发者现在可以自行选择使用哪个版本的虚拟机来执行智能合约。
RISC-V Extension:即 RISC-V 的扩展指令集,将提高执行某些位运算(bit manipulations)的能力,从而提升性能、减小代码大小并降低功耗。这让 CKB-VM 有更好的性能,特别是在 x86_64 处理器上运行时。
宏融合(Macro-Op Fusio):通过对 RISC-V 指令集的更新,允许将两条或更多条简单指令融合成一条更复杂的指令,从而更有效地执行。结合 RISC-V B 扩展指令集,将大大减少某些操作的 cycle 运行数量。一个例子是对 BLS 数字签名的支持得到了极大的改善,目前加密行业正在越来越多地采用这种签名。
系统调用(Syscalls):增加了三个新的系统调用,分别是 VM Version、Current Cycles 和 Exec。VM Version 可以让智能合约检测它是在哪个虚拟机环境中执行的;Current Cycles 允许智能合约在执行过程中查看到目前为止已经消耗了多少 cycle;Exec 允许当前正在执行的智能合约去执行另一个智能合约,允许更多的模块化代码,提高智能合约连续执行的可能性。
新的地址格式:即「CKB2021 地址」,新的地址格式可以通过 hash type 值指定虚拟机的版本。
Nervos Layer 1 为智能合约的执行提供了 CKB-VM v0 和 CKB-VM v1。这使得以前的智能合约可以使用 CKB-VM v0 保持完全向后兼容,而新的智能合约可以使用 CKB-VM v1。
建议所有使用 Layer 1 的开发者学习如何指定虚拟机的版本,以便他们可以充分利用 CKB-VM v1 中的新功能,或者在需要时恢复到 CKB-VM v0 以实现向后兼容。
脚本的 hash type 值现在用于指定匹配条件和目标虚拟机。在主网升级之前,hash type 值只有“0”和“1”,现在新增了“2”。
Hash Type 0:依赖 hash type “0” 的智能合约将继续使用 CKB-VM v0。 这是因为“0”的 hash type 意味着代码匹配是由 script code data hash 完成的,这意味着特定的二进制文件正在被执行。使用 hash type “0” 的现有智能合约将继续使用 CKB-VM v0,并完全按照主网升级前的方式运行。
Hash Type 1:依赖 hash type “1”的智能合约将使用 CKB-VM v1。这包括在主网升级之前和之后部署的所有智能合约。这是因为“1”的 hash type 意味着代码匹配是由 type script hash 完成的,这通常意味着脚本代码可由开发者自行升级。因为没有针对特定的二进制文件,而且存在升级路径,所以如果需要的话,开发者应该更新他们的代码,因为现在使用 CKB-VM v1 来执行了。
Hash Type 2:依赖 hash type “2” 的智能合约将使用 CKB-VM v1。这是因为 hash type “2”与类似于 hash type “0” 的特定二进制匹配。hash type “2” 在主网升级之前不可用,因此只有正在部署的新智能合约才能使用 hash type “2” 来指定 CKB-VM v1。
我们追求持续的进步,致力于让 Nervos 智能合约平台处于技术领先的地位。这些更新不仅改进了 Nervos 平台,而且通过与 RISC-V 和 Rust 的进展保持同步,我们的生态将继续受益于它们的改进,同时尽可能地保持安全。
虚拟机的改进,其影响的是 Nervos 平台的最底层,除了在 Nervos 生态中基于 Layer 1 做开发的人员外,其他人在很大程度上是感知不到的。尽管普通用户现在可能感觉不到差异,但这些更新将继续让 Nervos 在未来提供最佳的用户体验方面具有优势。
来源:Nervos Blog;原文链接:Virtual Machine Improvements
与 Nervos CKB 主网升级一起推出的还有 CKB-VM v1,它是可以在 Nervos Layer 1 上使用的虚拟机。这个新版本的 CKB-VM 提高了智能合约的执行效率,并增加了一些新功能供开发者在开发智能合约时使用。
同时,为了向后兼容,CKB-VM v0 仍然可用,开发者现在可以自行选择使用哪个版本的虚拟机来执行智能合约。
RISC-V Extension:即 RISC-V 的扩展指令集,将提高执行某些位运算(bit manipulations)的能力,从而提升性能、减小代码大小并降低功耗。这让 CKB-VM 有更好的性能,特别是在 x86_64 处理器上运行时。
宏融合(Macro-Op Fusio):通过对 RISC-V 指令集的更新,允许将两条或更多条简单指令融合成一条更复杂的指令,从而更有效地执行。结合 RISC-V B 扩展指令集,将大大减少某些操作的 cycle 运行数量。一个例子是对 BLS 数字签名的支持得到了极大的改善,目前加密行业正在越来越多地采用这种签名。
系统调用(Syscalls):增加了三个新的系统调用,分别是 VM Version、Current Cycles 和 Exec。VM Version 可以让智能合约检测它是在哪个虚拟机环境中执行的;Current Cycles 允许智能合约在执行过程中查看到目前为止已经消耗了多少 cycle;Exec 允许当前正在执行的智能合约去执行另一个智能合约,允许更多的模块化代码,提高智能合约连续执行的可能性。
新的地址格式:即「CKB2021 地址」,新的地址格式可以通过 hash type 值指定虚拟机的版本。
Nervos Layer 1 为智能合约的执行提供了 CKB-VM v0 和 CKB-VM v1。这使得以前的智能合约可以使用 CKB-VM v0 保持完全向后兼容,而新的智能合约可以使用 CKB-VM v1。
建议所有使用 Layer 1 的开发者学习如何指定虚拟机的版本,以便他们可以充分利用 CKB-VM v1 中的新功能,或者在需要时恢复到 CKB-VM v0 以实现向后兼容。
脚本的 hash type 值现在用于指定匹配条件和目标虚拟机。在主网升级之前,hash type 值只有“0”和“1”,现在新增了“2”。
Hash Type 0:依赖 hash type “0” 的智能合约将继续使用 CKB-VM v0。 这是因为“0”的 hash type 意味着代码匹配是由 script code data hash 完成的,这意味着特定的二进制文件正在被执行。使用 hash type “0” 的现有智能合约将继续使用 CKB-VM v0,并完全按照主网升级前的方式运行。
Hash Type 1:依赖 hash type “1”的智能合约将使用 CKB-VM v1。这包括在主网升级之前和之后部署的所有智能合约。这是因为“1”的 hash type 意味着代码匹配是由 type script hash 完成的,这通常意味着脚本代码可由开发者自行升级。因为没有针对特定的二进制文件,而且存在升级路径,所以如果需要的话,开发者应该更新他们的代码,因为现在使用 CKB-VM v1 来执行了。
Hash Type 2:依赖 hash type “2” 的智能合约将使用 CKB-VM v1。这是因为 hash type “2”与类似于 hash type “0” 的特定二进制匹配。hash type “2” 在主网升级之前不可用,因此只有正在部署的新智能合约才能使用 hash type “2” 来指定 CKB-VM v1。
我们追求持续的进步,致力于让 Nervos 智能合约平台处于技术领先的地位。这些更新不仅改进了 Nervos 平台,而且通过与 RISC-V 和 Rust 的进展保持同步,我们的生态将继续受益于它们的改进,同时尽可能地保持安全。
虚拟机的改进,其影响的是 Nervos 平台的最底层,除了在 Nervos 生态中基于 Layer 1 做开发的人员外,其他人在很大程度上是感知不到的。尽管普通用户现在可能感觉不到差异,但这些更新将继续让 Nervos 在未来提供最佳的用户体验方面具有优势。
No comments yet