Polkadot 的可靠性如何？有哪些方面还能提升？| Polkadot Decoded
共 5966字，需浏览 12分钟
·
2024-07-24 22:58
在 Polkadot Decoded 2024 大会上，来自 Parity 的 Pierre Aubert 讨论了 Polkadot 的可靠性，以及 Polkadot 接下来应该提升的方面。
今天，我想谈谈 Polkadot 的可靠性。虽然过去关于这个话题的讨论并不多，但它非常重要，因为人们对 Polkadot 的信任与我们能够保证的可靠性紧密相关。关键不在于我们做了什么，而在于我们能保证什么。
Polkadot 复杂吗?
我到这里工作只有九个月，期间我一直在听取很多人的意见，试图了解 Polkadot 做得好的和不足的地方。这段旅程让我意识到对 Polkadot 的看法非常多样化。有些人认为技术层面很棒，但构建一个平行链极其复杂。总体来看，大家一致认为构建并不容易。
在技术方面，有人认为 Polkadot 比任何 L2 都要好得多，他们根本无法与我们竞争。另一部分人则认为 Polkadot 过于复杂，他们更愿意去有更多流动性和用户的地方。同时，有很多创新在进行中，在短短九个月里有两个大事件，一个是 Plaza，另一个是 JAM，我稍后会谈到它们。
对于我和 Polkadot 来说，理解我们能做什么以便在 Polkadot 上有更好的体验是很复杂的，同时也要考虑那些还未加入 Polkadot 的人，我们应该如何与他们沟通，以及我们应该构建什么，以便他们加入时有更好的体验。
Polkadot 的愿景实现了多少
那么，Polkadot 的愿景是什么呢？
理论上，Polkadot 是一个去信任、安全、可扩展、可靠、便宜且易于使用的区块链构建环境。
就目前情况而言，我们实现了哪些愿景呢？
去信任做到了，安全大部分做到了，可扩展可能做到了，可靠部分做到了，非常便宜可能不是，使用也不是特别复杂。
我在 Polkadot 上构建了一些小应用，发现这是一项年轻的技术，文档不完美，但也不是特别复杂。
接下来呢？我想谈谈接下来六个月我们想做什么。在接下来的六个月里，计划是在每个方面都做一些改进，以提高可靠性，让人们对我们更有信心。
我想展示的是我们需要改进的方向。我们需要在安全方面稍微改进一点，需要大幅度提高可扩展性，还需要大幅度提高可靠性，我认为这是我们的弱项。我认为在某些领域我们表现很好，例如创新或去中心化。
安全性
首先是安全，Polkadot 链本身的安全性是非常好的。但还有一些不清楚的安全问题，安全是一个复杂的问题，例如你可以有一个超级安全的系统，但如果配置错误，你就不安全了。所以我们想专注于几个方面，我会解释第一个，因为我认为它很重要。
我们想要消除单边访问，单边访问意味着一个人不应该能够单独对 Polkadot 做出更改，例如运行时、节点等所有这些东西都不应该允许一个人单独完成，因为如果需要两个人，那就需要两个人共同做出更改，这样就大大减少了坏人的数量。首先，我们构建代码并推送代码时，不应该允许一个人单独完成，这将最小化风险。
第二个是依赖问题，例如构建 SDK 时，你会拉入大量的包，构建 Polkadot 也是一样，你会拉入成百上千个包，而你并没有编写这些代码，即使它们当时是安全的，但下一周就没有保证了。所以我们需要逐步减少依赖项，因为太多了，我们无法手动查看所有这些代码。有些例子说明了依赖项带来的漏洞，代码本身是安全的，但依赖项不是，这很难控制。我们需要缩减依赖项，第一步是组织并清楚了解我们的依赖项，并可能制定一些政策，告诉人们从现在开始不要再增加新的依赖项，除非有充分的理由。
可靠性
可靠性，这很有趣，因为甚至没有一个定义能说明 Polkadot 或 Kusama 是可靠的。
这是什么意思？我认为这是我们缺失的一项内容。当我与想加入生态的公司交谈时，他们会问这些问题，例如你的 SLO（服务等级目标）是什么？你能对运行在 Polkadot 和 Kusama 上的项目提供什么保障？我有点语无伦次，因为没有定义。
所以我们需要两个东西，一个是定义，这并不复杂，然后我们需要执行它。我们讨论过创建一个新的集体，专注于基础设施，我认为这是他们可以做的第一件好事，提供 SLO。SLO 对我们来说并不那么重要，但对想加入的人很重要，因为这是他们习惯的东西。我认为对我们来说，这也有助于我们从 “我们很棒” 转向 “让我们衡量我们所做的并随着时间的推移改进”，如果有需要的话，因为我甚至不知道我们是否真的好。
例如，Polkadot 正常工作意味着我们在 Kusama 上测试得很好，但我们没有很好的控制方法，我们有点幸运。举个例子，运行时推送到链上，所以你有上一个版本，然后有新的版本，没有渐进过程，如果我们犯了错误，就会让链崩溃，好在我们还没发生过，但这是非常有风险的事情。
API 或兼容性是另一个让我感到惊讶的地方，开发系统和 SDK 优化了开发人员的速度。如果你问开发人员他们想要什么，他们会说我们不想有太多约束，兼容性是复杂的，我们不想要。但如果你问用户，他们想要的是相反的，他们希望最大程度的稳定性，因为每次更改他们都不满意。所以我们需要在这里找到一种折衷，我们希望保持一定的速度，因为你也想要新功能，越稳定新功能越少，而另一方面，我们需要更加稳定。
Polkadot 目前的测试水平还有很多可以改进的地方。现在，我们对测试的控制还不够全面。具体来说，当我们说 Polkadot 正常工作时，这到底意味着什么？是指中继链工作正常，还是所有平行链都工作正常？未来的应用程序将会同时使用多个平行链，所以对这些应用程序来说，所有平行链都能正常工作才是关键。
目前，当我们发布新功能或更新时，我们没有对所有平行链进行全面的测试，确保它们都能正常工作。如果有任何平行链出现问题，我们应该能够及时发现并回滚更新，或者采取其他措施来解决问题。这就涉及到发布的问题，即在我们构建并发布新的运行时版本后，如何控制发布过程，确保不会对系统的稳定性造成影响。
所有这些事情都是典型的可靠性话题，我们需要在这些方面做一些小改进，因为我们目前的成熟度还没有达到新客户的期望。我不是说我们做得不好，只是因为我们没有数据和数字来证明我们做得很好。
可扩展性
可扩展性也是一个有趣的问题，一方面有人说我们已经很快了，可以轻松吸收以太坊的所有交易，另一方面则是来自 Web2 世界的公司告诉我们，他们想要每秒处理 100 万笔交易来启动一个原型，他们不是在谈论每秒几千笔交易。
虽然 Polkadot 目前的表现不错，但还不能满足 Web2 公司的需求。为了满足这些需求，我们需要逐步改进和扩展。第一步是实现弹性扩展，这在 H2（今年下半年）的路线图上已经有计划。然而，即使是现在的客户也在挑战 One Core 的性能极限，所以我们需要进一步提升 One Core 的性能，并更加专注于扩展。
比如，我们可以采用乐观扩展的方法，或者向客户解释他们何时可以读取区块数据，因为大多数情况下，他们可以在区块由协调器生成后读取，而不需要中继链的验证。因此，我们需要更清楚地解释这些细节，这将有助于系统的扩展。我认为这是我们非常擅长的领域之一。
可用性
至于可用性，这有点复杂，取决于你想要构建什么。如果客户或开发者倾向于使用 Rust 和 TypeScript，我认为我们有一些工具可以供他们使用，尽管不是完美的。如果你想在移动设备上构建应用，现有的库就少很多了。Nova 有一个库，但我认为我们主要考虑的是 Web 应用，但有很多应用程序不是 Web 应用，有很多人想要构建原生应用，但也有一些人想要在现有的应用程序上连接区块链。当你与人们交谈时，他们有大型的 C++ 应用程序或大型 Java 应用程序，他们会问你是否有 Java 的 SDK 来连接你的东西，而我们没有。因为我们没有 SDK，很多人甚至不会考虑我们。所以，我认为未来的趋势是我们应该认识到这个世界非常大，不仅仅是构建 Web 应用，因此我们应该逐步提供更多语言支持。
另一个令人惊讶的是，区块链很好，你可以看到所有的状态和数据，但同时我们存储状态的方式很复杂，从状态中读取数据也很困难。例如，如果你想要你的质押历史，从状态中提取这些信息是个噩梦，应该有 TypeScript 库或其他工具，你只需要传入一个地址，它就会给你质押历史。没有人需要知道有两个质押点，并且它随着时间的推移而改变，并且分布在区块链中。如果你是质押专家，你可能想知道这些，但大多数人不需要。如果你在构建一个钱包，你只想显示质押历史，你希望 API 提供按地址而不是按网络的接口。
因此，API 的设计并不是特别方便使用，我认为它暴露了太多你不需要知道的链上数据，大多数人不需要知道这些。所以，增加一个抽象层会很有帮助，对我们来说也会很好，因为当我们发布运行时时，我们可以检查这个 API 是否以不破坏客户的方式工作，这比在状态层面检查要容易得多，因为我们不知道你如何读取状态。因为我们没有解释清楚，当然人们会反向工程状态存储方式，等等，这也解释了为什么我们在进行更改时会破坏人们的系统，因为我们并不真正了解他们如何使用状态。但正常情况下，他们不应该知道这些。如果你考虑传统应用程序中的 “模型-视图-控制器” 架构，模型的工作就是隐藏状态存储方式，这是有原因的，它隔离了组件，允许你进行更改而不破坏整个系统。
我们正在做的另一件事叫做 Omninode，目的是在不久的将来让构建平行链变得更容易，你不需要自己的基础设施，Omninode 将与生态系统内的所有合作伙伴集成。所以你只需要编写平行链的部分，生态系统的其他部分由合作伙伴完成。我们现在正在设计 Omninode，如果你有兴趣可以在论坛上查看帖子并参与规范的讨论，我们非常希望能得到你的反馈，以更好地了解我们如何帮助你。当然，这将在 2025 年，根据 2024 年这一倡议的结果，我们会决定具体做什么。
Plaza（广场链）
下一个大事件是 Plaza，不确定是否大，但我认为它很重要。这个想法是资产中心持有所有资产，因为它是一个系统平行链，用 DOT 支付手续费。
如果我们在其中支持 EVM 构建应用程序会更容易，因为你不需要了解链上编程，这看起来很像一个 L2，这是大家习惯的东西。我认为这对目前在 Polkadot 上的人不重要，但对那些我们希望加入的人很重要。我们可以构建一个非常接近他们习惯的环境，而且更容易使用。这有点像赌注，看看它是否会成功。目的是吸引更多客户，同时对现有生态系统施加压力。我不知道结果会如何，但我知道如果我们不改变策略，不试图提供更容易使用的产品，吸引更多客户会很困难，我们需要更多外部客户。
目前正在进行一项公投，目的是了解社区是否希望在资产中心支持 EVM。Robert 提出了一个想法，并在一个帖子中讨论了他所谓的 Plaza，这个概念包含了资产中心、EVM 以及当前中继链上的一些功能。
例如，他提到，没有充分的理由让质押功能留在中继链上，它应该移到其他地方，比如资产中心，这将简化常见用例的集成。
关于我们是否能构建一个比 L2 或以太坊更好的系统，我还不知道。目前的方向进展不错，我认为技术栈可能会很好，但是否足够，我还不确定。因此，我认为 EVM 解决方案的重要性在于它的集成质量、桥接方法、文档质量以及市场推广等方面。这些部分不会由 Parity 完成，因为 Parity 没有足够的资源。我们唯一能做的就是构建一个优秀的技术产品，所以未来需要大家共同努力来推动这个事情的发展。
JAM 迁移
接下来是 JAM，Gavin 多次介绍了 JAM。一方面人们对它非常兴奋，因为它是新事物，有路线图和下一步计划。但每次有变化人们都会担心迁移问题，在 JAM 启动和实现之间，平行链开发者会面临什么？
我理解，我也讨厌大的迁移，这是个风险。但是我想强调，Parity 会长期支持平行链，因为我们拥有很多系统平行链，我们需要这些系统平行链继续工作。所以我们会支持平行链可能长达十年，这样如果你还不想迁移，就不用去迁移。如果 JAM 非常出色，所有人都迁移到 JAM，那么我们可以关闭平行链；但如果 JAM 很好，而你不需要它提供的功能，人们会继续使用平行链。如果我们的客户留在平行链上，我们会继续维护这个技术栈，这并不意味着我们会大力投资这个栈，但它会得到支持，你不需要迁移，直到你真正想要迁移的时刻。
总结
总结一下，即使 Polkadot 并不是完美的，但它运行得相当好，有潜力变得很棒。我认为逐步改进的方法也是一种高效的进步方式。
原文：https://www.youtube.com/watch?v=DLofyGI3mw8&t=14s
阅读更多：
关注我们：
PolkaWorld Telegram 群：
-
https://t.me/+z7BUktDraU1mNWE1
PolkaWorld Youtube 频道：
-
https://www.youtube.com/c/PolkaWorld
PolkaWorld Twitter：
-
https://x.com/polkaworld_org（英文） -
https://x.com/polkaworld_pro（中文）