作者：Brett McLain，工程总监 – Crypto、Fiat、Staking 如果您对加密货币、支付或抵押感兴趣，并希望帮助构建未来的金融系统，融资工程团队 @ Kraken 正在招聘！ 大约十年前 Kraken 推出时，只支持三种加密货币：BTC、LTC 和 XRP。 如今，Kraken 支持 33 条区块链上的 82 种资产，以及 8 种加密货币的 Staking 服务。 为了促进 Kraken 每年数百万的存款、取款和抵押交易，加密工程团队运营了数百项服务，以确保资金进出交易所的顺畅流动。支持这些服务的区块链软件经常更新；对于一些更活跃的区块链，硬分叉和软分叉本质上可以是每月一次，而其他像以太坊这样的区块链则是每年两次。一般来说，我们的区块链基础设施每周至少会有一些软件更新。 支持和更新如此大量不同的服务，同时构建新服务可能是一项艰巨的挑战。 在过去的 12 个月中，我们的团队增加了对以下方面的支持： - 60 种新加密货币： 39 x ERC20 代币Polkadot（在主网启动时）草间弥生Filecoin（在主网启动时）流程（在主网启动时）卡瓦能源网络令牌（在主网启动时） USDT (TRC20) 10 x 平行链众包索拉纳1 x SPL 代币（血清）米娜 - 39 x ERC20 代币 - Polkadot（在主网启动时） - 草间弥生 - Filecoin（在主网启动时） - 流程（在主网启动时） - 卡瓦 - 能源网络令牌（在主网启动时） - USDT (TRC20) - 10 x 平行链众包 - 索拉纳 - 1 x SPL 代币（血清） - 米娜 - 8 种新的抵押资产： Polkadot（在主网启动时）草间弥生以太坊 2.0（在主网上线时）流程（在主网启动时）卡尔达诺宇宙卡瓦索拉纳 - Polkadot（在主网启动时） - 草间弥生 - 以太坊 2.0（在主网上线时） - 流程（在主网启动时） - 卡尔达诺 - 宇宙 - 卡瓦 - 索拉纳 这些成就是在维护我们现有集成的同时取得的。加密团队的工程师不仅负责内部编写的网关软件，还负责我们网关所依赖的区块链基础设施的维护和部署。在这些项目上开发区块链的节奏可能非常快，经常会出现重大变化和新颖的新功能，有时甚至几乎没有任何警告。 那么，Kraken 如何在跟上区块链发展的快节奏的同时，每年发布数十款新产品呢？ 端到端 (E2E) 测试！为什么我们重视 E2E 测试并避免模拟 从 Kraken 的早期开始，重点一直是 E2E 测试是工程师可以构建的最有价值的测试类型。单元测试有其一席之地，但许多对复杂集成缺乏经验的开发人员倾向于为他们构建的每一段代码编写单元测试，因为他们相信他们正在提高他们正在开发的软件的整体质量。 这条道路虽然充满善意，但往往会导致很多痛苦。过度依赖单元测试往往会巩固您的架构；这就像在整个代码库上浇上一层环氧树脂。您将代码与其测试紧密耦合，从而使代码更加僵化、不灵活并且难以重构。如果您需要进行更改，您可能需要对测试进行重大更改，并且在某些情况下，将它们完全丢弃。重构代码是工程团队在他们的工具包中拥有的一项关键能力，任何增加重构难度的东西都应该在引入之前仔细评估。在重构代码时，设计良好的 E2E 测试通常不需要很多更改，并且可以灵活地调整应用程序的内部结构，同时确保它继续按预期运行。 这是否意味着您不应该编写单元测试？一点也不！在许多场景中，单元测试是完美的解决方案，但是我们发现对于复杂的集成，E2E 测试效果更好。通常，单元测试在为满足以下条件的代码编写时最有效： - 算法复杂，具有许多边缘情况。 - 范围严格，要求明确。 - 完成一个工作单元。 - 无国籍。 这些小的、范围狭窄的复杂代码通常是更大应用程序的构建块，即使发生重构，这些功能也不太可能改变。在我们的世界中，这可能是地址派生、地址验证、交易签名等。 这里的关键要点是，作为一个小型工程团队，我们永远无法保持我们目前支持的服务量，并在没有端到端测试的情况下构建新产品。单元测试应该被视为赌注，但孤立地看，它们不足以让我们跟上这个不断发展的空间。相反，我们选择大量投资于强大的集成和 E2E 测试集，以验证我们的服务将在最常见的操作模式下成功运行。 E2E 测试的挑战 尽管 E2E 测试可能很强大，但它们并不是万能的。当与第三方服务集成时，这些类型的测试通常会失去很多价值，因为需要模拟某些端点或接口才能完全测试特定功能或调用的流程。模拟仅与您对模拟的服务的理解一样好，因此，当更新频繁且本质上较大时，它们可能容易出错。维护自己的代码和模拟程序违反了 DRY 原则（不要重复自己），这是 David Thomas 和 Andrew Hunt 在“The Pragmatic Programmer”中创造的术语。在他们的书中，他们指出“在一个系统中，每一条知识都必须有一个单一的、明确的、权威的表示。”创建任何服务的模拟版本意味着该服务现在有两个可能不同的副本：您的模拟版本和实际版本。翻译模拟依赖行为的错误现在是另一个需要考虑的问题。 Regtests 来救援 值得庆幸的是，大多数区块链都支持运行临时私有网络的能力，这些网络可以作为我们持续集成 (CI)/持续部署 (CD) 流程的一部分启动。最流行的例子是比特币的回归测试（regtest）模式。当您使用 `-regtest` 选项启动 bitcoind 时，它会创建一个您可以完全控制的新本地区块链环境。 regtest模式的主要特点是你可以随意挖掘任意数量的区块，让你的E2E测试可以完成所有类型和变化的存取款的往返，在几秒钟内模拟数百个场景。可以在 regtest 模式下轻松模拟边缘情况和其他独特场景，例如多重签名交易、重组、按费用替换 (RBF)、子代为父代 (CPFP) 等！这些测试不仅确保我们的代码不包含错误，还验证区块链和分类账的最终状态，以确保一切按预期运行。 作为在 Kraken 上添加对新加密货币支持的过程的一部分，融资团队为所有新上市建立了一个 regtest 框架。这段代码是我们维护制度的基础：每当发布新版本时，只需更新区块链节点版本并重新运行我们的 CI 管道以确保没有重大更改。仔细阅读发行说明并与社区合作仍然非常有必要，但这些测试让我们有信心发布我们本来不会拥有的新版本。创意解决方案 对我们来说不幸的是，并非所有区块链都像比特币一样经过实战考验。新的区块链通常会引入新的概念，为了让我们的客户能够访问最令人兴奋的新技术，Kraken 更喜欢在尽可能接近主网开始时启动对新区块链的支持。为了在发布日期或临近发布日期安全地支持新资产，Kraken 有时需要开发复杂的测试工具，以获得对集成的信心并确保客户资金不会面临风险。 一个完美的例子是，在 2020 年 12 月 1 日主网上线仅 3 天后，Kraken 就推出了对 Ethereum 2.0 的支持。尽管世界各地成千上万的个人和公司帮助在 Medalla 和 Spadina 等多个测试网上测试了 Ethereum 2.0，但我们仍然决定通过这种集成将 regtests 的概念提升到一个全新的水平。我们很早就知道以太坊 2.0 将是一个重大的发展，而且这一信念已被证明是正确的，因为迄今为止数百万 ETH 已被抵押在信标链上，其中包括由 Kraken 客户抵押的 800,000 多个 ETH。 您可以在下面看到一组服务的图表，每次开发人员将代码提交到我们的一个 ETH2 代码存储库时，我们的持续集成 (CI) 管道都会启动和拆除这些服务。 概括地说，测试流程是： - 启动 ETH1 主节点和备用节点（它们每个节点轮流挖掘以达成共识），其中包含初始数量的 ETH 用于测试。 - 使用特殊的最小配置模式将 ETH2 信标链节点作为私有链启动，其中仅需要 16 个验证器来激活创世。 - 将 ETH2 智能合约部署到 ETH1 区块链。 - 将 ETH 存入 ETH2 存款合约，在该合约中，资金被烧毁并在 ETH2 外部验证器节点上创建验证器。这些验证者只是在操作 ETH2 网络，并且被视为在任何 Kraken 验证者之外。 - 启动 ETH1 和 ETH2 区块浏览器。 - 启动数据库。 - 启动网关和签名者。 - 插入客户请求以质押 ETH -> ETH2。 - 网关接收客户端请求并将 ETH 发送到 ETH1 区块链上的存款合约，并在 ETH2 内部验证器节点上创建相应数量的验证器。验证器被分为内部和外部验证器集，以便我们可以测试当我们的验证器宕机时会发生什么（测试削减、惩罚、丢失的奖励），并查看当网络的其余部分宕机或离线但我们的验证器时会发生什么保持起来。 - 监控直到验证者在 ETH2 链上活跃，开始跟踪奖励、支出、测试削减和处罚、丢失奖励检测以及向客户支付奖励。 - 对所有交易运行我们单独的财务对账流程，以确保我们所有分类账中的所有内容都正确匹配。 以上只是我们测试框架内正在发生的事情的高级总结；还有许多其他测试、检查和验证。如果开发人员需要调试某些内容或查看任一网络的状态，他们可以咨询区块浏览器以一目了然地查看到底发生了什么。我们通常不会在 CI 管道中包含区块浏览器，但考虑到集成的复杂性，在开发阶段可视化链上正在发生的事情会很有帮助。 您可能认为这会极大地延迟我们的 CI 管道，但幸运的是事实并非如此。目前，我们以太坊 2.0 存储库的完整 CI 管道只需 14 分钟即可运行。这包括审计/构建所有依赖项、启动所有服务、将各种智能合约部署到区块链、挖掘区块、创建验证器，然后运行所有 100 多个测试场景。最后的想法 在 Kraken 为每个区块链集成开发全面的 E2E 测试会消耗大量的工程资源。这是我们乐意付出的代价，因为我们最关心的是客户资金的安全并确保他们在我们的平台上拥有优质的体验。如果我们在构建新集成时花更少的时间进行测试，我们的团队能否发布更多产品？毫无疑问。然而，这样做不仅违背了工程团队的精神和价值观，而且违背了整个公司的精神和价值观。这些测试确保我们可以安全地更新到新版本的区块链软件，在硬/软分叉期间增加信心，并在部署更改时减少开发人员的压力。 为什么 Kraken 工程师是业内最受尊敬的工程师？ 来自 Kraken 工程副总裁 Steve Hunt 的这条消息概述了我们的价值观和帮助其他区块链工程师的奉献精神。 分享这个： - 推特 - Facebook - 像这样：喜欢加载...