对所有 Blogs 进行分类，来这里快速找到你正在寻找的 Blog。

过去，在 CKB 的锁脚本中，签名验证算法与其他交易验证逻辑是紧密耦合的，比如，anyone-can-pay 锁脚本。这样做的一个原因是为了简化 CKB 脚本的任务。在早期，您肯定希望限制您正在处理的范围，以确保构建出的脚本足够安全。

但是慢慢地，我们越来越了解如何构建 CKB 脚本。与此同时，将签名算法和锁脚本逻辑的捆绑带来的问题也逐渐得到关注：假设我们有 N 个签名验证算法，M 个特定的锁脚本逻辑，我们就需要构建 N*M 个锁脚本才能完成所有的组合。这将带来巨大的维护负担，也将会造成链上资源的浪费。关于这个问题，有什么解决办法吗？

在智能合约平台上，用户通常只有一个一直使用的地址。但是，Nervos 的 cell 模型提供了一个不同的设计范例，用户在 Nervos 上可能会控制许多有着不同 lock script 的不同的 cells。

当我们在和区块链进行交互时，这样的设计提供了强大的灵活性。为了控制 cell 的所有权，开发人员可以指定条件然后通过使用任意数量的密码学原语来控制这些 cells 的所有权。这样灵活的设计可以在 P wallet 中看到。

通道网络（Channel Network）可能是 layer2 舞台上最耀眼的角色。一个广泛部署的通道网络可以最大化交易吞吐量（无上限！），可以最小化交易处理延迟（可以和连接各方的网络一样快），可以增强交易的隐私性，甚至可以为区块链提供一定的互操作性。简而言之，如果运用得当，通道网络将会是解决问题的灵丹妙药。

我一直以来对确定性执行的问题很感兴趣。我们在多线程模型上花了很大时间。我们大部分人都应该遇到过一些只在一定概率范围内发生的 bug。即使你已经准备好了一个修复程序，你也不能确定它是不是还会再次发生，你所能做的不过是测试，测试，再测试，并希望这样的问题不会再次出现。我们可以确定地进行调试并拍着胸脯说这是 100% 确定的，这是每一位工程师的梦想，而这个问题已经被解决了。

在构建 CKB 时，我们选择使用了一个通用的 VM，所以它不会绑定任何特定的编程语言。这种模式当然有其优点，但它也会带来一些问题。我们经常被问及的一个问题是：在 Nervos CKB 上，我应该用什么语言来进行编程？让我们试着回答这个问题。

在区块链世界中，人们普遍认为，在可用性方面，帐户模型比 UTXO 模型更有优势，我一直在努力弥合区块链中的 UTXO 模型和帐户模型之间的差异。