Odaily星球日报|答应我,以后别再分叉了( 二 )


假设我们在虚拟机中运行整个客户端 。 我们用 Java 或 Scala 编写它 , 在区块链上部署 Java 字节码 , 或者我们做一些类似于苹果公司做的事情 , 用 LLVM 支持的本地语言编译并部署 LLVM 位码 。 好吧 , 这是更好的 , 但是不管你使用的 VM 格式是什么 , 你都在很大程度上限制了你可以在其中构建客户端的语言 。 另外 , 你还在区块链上部署一个巨大的 blob , 而在区块链里空间是很珍贵的(或者应该是很珍贵的 , 但实际上存储租金并没有得到广泛的实现) 。
这忽略了这样一个事实 , 即当你构建一个 LLVM 语言时 , 你会根据操作系统生成不同的位代码 , 苹果只能逍遥法外 , 因为他们的操作系统在不同的设备上 , 他们部署了兼容的 api 。
最后 , 在链上部署整个客户端的任何策略最终都会遇到这样的问题:处理回滚会将整个事情变成一场滑稽的闹剧 , 因为回滚策略是由回滚的内容定义的 。 面对链上更新 , 定义分叉选择规则或回滚策略没有好的答案 。
假设我们将定义区块链逻辑的代码从其余代码中分离出来 , 然后将其编译为 VM 字节码 。 我所说的 “区块链逻辑” 是指定义区块链逻辑的代码 。 以太坊负责账户、余额和智能合约 。
ZCash 对交易进行零知识证明 。 比特币的基础计算效率极低 。 在一般情况下 , 是代码告诉我们如何根据交易更改状态 。 我们在网络、实现速度等方面仍然存在竞争 , 虽然这意味着我们不能用这种方法更新网络代码 , 但是在一个分布式网络中保持多个不同版本的节点比让这些节点在不断更新的可变状态上达成共识要好得多 。
我们可以使用像 libp2p 这样的可扩展网络协商协议 , 允许新节点使用新的通信协议 , 同时仍然允许旧节点参与 。 为了避免前面提到的回滚问题 , 我们必须将逻辑分离到共识级别以下 。 这意味着我们只能更改将交易映射到状态更改的代码 。
这确实意味着我们不能改变分叉选择的规则、回滚策略或共识算法 , 但是我们必须在某个地方进行抽象权衡 。 共识算法不能改变 , 因为它可能会使区块无效 , 并且我们只能允许改变链上影响状态的东西 。
设计我们的接口 为了便于论证 , 并且因为你可能已经知道我在这里要引入一些东西 , 让我们将这个逻辑称为区块链的 “runtime” 。
如果我们从头开始构建一个新的链 , 我们可以选择自己的共识算法等 , 我们希望使我们的代码尽可能通用 。 因此 , 我们希望让 runtime 做出尽可能多的选择 。
假设我们想要同时支持许可的私有链和无许可的公有链 。
例如 , 如果我们选择像 Tendermint 或 PBFT 这样的 PoA 共识算法 , 那么我们可以同时拥有这两种算法 , 允许 runtime 选择权限 。 这意味着 , 如果我们想改变在权限之间达成共识的方式 , 那么我们仍然只能硬分叉 , 但实际上 , 这一系统最终还是非常灵活 。 使用在链上选择权限的 PoA 系统 , 我们可以创建许可链(意味着只有某些方可以参与网络)和无许可链(意味着任何人都可以参与网络) 。
我们可以对任何一种策略使用任意数量的策略 , 但例如 , 我们可以通过对权益不同的质押者进行随机选择 , 来确定权限池(类似节点的意思) , 从而创建一个权益证明链 。 这解决了升级策略不确定的问题:升级不能追溯地更改前一个区块的权限集 , 只能更改未来权限集的选择方式 。
runtime 还应该能够自己决定何时升级以及如何升级 , 因为我们可以使用链上治理来执行这些升级 。 由于治理也是在 runtime 中定义的 , 这意味着你可以对 runtime 进行编程 , 以限制允许治理更改的内容 。
也许不允许改变治理结构本身 , 但其他一切都是公平的游戏 。 也许它只允许调整一些小事情 , 但系统的基本规则必须保持不变 。 也许你可以改变任何事情 , 但不同的权力层次需要不同级别的票数 。 这完全取决于 runtime 的开发人员 。


推荐阅读