原文：Stubborn, or Steadfast?
翻译及校对 ：「Starknet 中文社区」
作者 ：Eli Ben-Sasson｜StarkWare 联合创始人
📑 转载请注明出处 🕹️

在市场看来并不重要的安全领域，为什么我们仍在坚守？

本周，我和 Starknet 的核心工程师之一 Ilya Lesokhin 聊了聊，他提出了以下问题：

当市场明确表示：“别说废话了，尽快部署能部署的东西，只要你们承诺你们的安全技术稍后能到位就行？” 我们为什么还要如此努力地坚守我们的技术为先的原则，为每一次状态更新提交链上的 STARK 证明，试图用新的 STARK 友好型虚拟机 — Cairo 来尝试不可能的任务。

这个问题引发了我的思考。作为一名科学家，我热爱我共同发明的这项技术，并希望看到它在实践中得到部署和使用。但是，从企业家和商业人士的角度来看，我不得不承认，坚持技术为先的原则确实限制了我们的应用速度。因此，我将从商业角度出发，谈谈我们仍然选择坚守技术的原因。

骑虎难下：「骑虎难下」这个比喻描述的情况是：你行动过快，以致于无法改变方向或修正任何错误。在我们的语境中，假设我们采用了目前最快的区块链技术堆栈，并宣称「这就是我们的技术，开始使用吧，STARK 证明随后就来」。这样做就意味着我们正骑上老虎出发。这只「老虎」，即那个无证明但速度极快的底层技术堆栈，会持续加速，向着更低的成本和更大的规模前进。在任何特定时间点，如果我们想要暂停来添加缺失的技术，市场就会问：“为什么停下来？为什么要从老虎背上下来？我们愿意再等等（再添加技术），因为我们享受这趟骑老虎的旅程。”问题是，这种做法不可避免地会有清算的一天（参见图 1），某一天某个攻击者会以灾难性的方式攻破系统，因为我们从来没有设法安装必要的安全技术（还记得「门头沟事件」吗？）。如果要对你的合作伙伴、客户和团队成员负责，就意味着不能走这条路。

真正的信仰者会选择正确的建设方式 ：我们来看一个虚构的例子。想象一下，Alice 和 Bob 在商业航空初期阶段竞争。Alice 正在制造一台真正能飞的机器，这是一项复杂的艰巨任务。她的首批模型只能飞行几米远，除了勇敢的飞行员外，什么也运载不了。另一方面，Bob 则开着一列货运火车，声称他正在给这辆火车加装机翼，但与此同时，这列火车将仍在铁轨上行驶。由于这个精明的商业决策，比起 Alice，Bob 在早期拥有巨大的商业优势，因为客户会因为他用「飞机 」运输货物而付钱给他。这个有些荒谬的例子想要表达的观点是：即使商业航空有任何独特的附加价值，其在航空发展初期也并不明确（同理，如今在 STARK 和有效性证明方面的附加价值也仍不明确）。最终技术商业变现的唯一方法是遵循 Alice 的路径。

大规模应用的滩头阵地 ：区块链的大规模应用尚未开始，将所有加密货币的总 TPS（每秒交易量）以及 TVL 与传统金融的相应数据进行对比，或衡量人们在日常消费交易（比如常说的一杯咖啡）中使用加密货币的比例，都可以清楚地看出这一点。我们正在构建面向全球规模的加密技术，我们相信我们的技术，即 STARK 证明以及由 Cairo 和 Starknet 提供的可扩展性和安全性，对于区块链的大规模应用至关重要。因为它可以在不降低安全性和不增加信任假设的情况下进行大规模扩展。专注于为这种情景构建正确的技术，我们就不能妥协于那些目前看似「足够好」但在大规模使用压力下会崩溃的解决方案。类比来说，为高速公路建一座桥比为单行道建一座桥更难，而且需要更长的时间才能建成。但当巨大的交通流到来时，人们使用的将是更坚固的桥梁。

我们如何守卫自己走过的捷径？在去中心化和安全性方面，我们不得不做出一些妥协。特别是，我们起初采用了单一的中心化排序器/证明器，并且系统升级是中心化管理的。在极端情况下，这些选择也可能导致灾难性的故障。如果所有项目在开发技术时都在走某些捷径，那么是什么让一种捷径（比如我们正在走的这种）比另一个团队走的捷径更具优势呢？

我想给出两个回答。首先，相比于直接在核心技术做出妥协来说，避免在构成技术核心主张的引擎和动力源方面做出妥协会比较好。当制造一架坚固的商用飞机时，你不应该在其飞行能力上做出妥协，但可以在诸如实现夜间飞行或恶劣天气飞行的能力方面做出一定的妥协。

第二个回答是，只要坚定不移地推广核心技术，就更有可能去掉早期项目中普遍使用的「辅助轮」。对于 Starknet 来说，这意味着我们相信，将中心化系统的排序器和证明器去中心化，要比在本不支持 STARK 证明的系统中添加 STARK 证明来得更容易。

当然，我们的推理也可能是错误的，许多拥有伟大愿景和清晰价值观的公司也因种种原因失败了。这篇简短的文章的重点是为大家阐述，在当前这个早期阶段，我们是如何思考我们所做的技术和商业选择的。

原文：Stubborn, or Steadfast?
翻译及校对 ：「Starknet 中文社区」
作者 ：Eli Ben-Sasson｜StarkWare 联合创始人
📑 转载请注明出处 🕹️

在市场看来并不重要的安全领域，为什么我们仍在坚守？

本周，我和 Starknet 的核心工程师之一 Ilya Lesokhin 聊了聊，他提出了以下问题：

当市场明确表示：“别说废话了，尽快部署能部署的东西，只要你们承诺你们的安全技术稍后能到位就行？” 我们为什么还要如此努力地坚守我们的技术为先的原则，为每一次状态更新提交链上的 STARK 证明，试图用新的 STARK 友好型虚拟机 — Cairo 来尝试不可能的任务。

这个问题引发了我的思考。作为一名科学家，我热爱我共同发明的这项技术，并希望看到它在实践中得到部署和使用。但是，从企业家和商业人士的角度来看，我不得不承认，坚持技术为先的原则确实限制了我们的应用速度。因此，我将从商业角度出发，谈谈我们仍然选择坚守技术的原因。

骑虎难下：「骑虎难下」这个比喻描述的情况是：你行动过快，以致于无法改变方向或修正任何错误。在我们的语境中，假设我们采用了目前最快的区块链技术堆栈，并宣称「这就是我们的技术，开始使用吧，STARK 证明随后就来」。这样做就意味着我们正骑上老虎出发。这只「老虎」，即那个无证明但速度极快的底层技术堆栈，会持续加速，向着更低的成本和更大的规模前进。在任何特定时间点，如果我们想要暂停来添加缺失的技术，市场就会问：“为什么停下来？为什么要从老虎背上下来？我们愿意再等等（再添加技术），因为我们享受这趟骑老虎的旅程。”问题是，这种做法不可避免地会有清算的一天（参见图 1），某一天某个攻击者会以灾难性的方式攻破系统，因为我们从来没有设法安装必要的安全技术（还记得「门头沟事件」吗？）。如果要对你的合作伙伴、客户和团队成员负责，就意味着不能走这条路。

真正的信仰者会选择正确的建设方式 ：我们来看一个虚构的例子。想象一下，Alice 和 Bob 在商业航空初期阶段竞争。Alice 正在制造一台真正能飞的机器，这是一项复杂的艰巨任务。她的首批模型只能飞行几米远，除了勇敢的飞行员外，什么也运载不了。另一方面，Bob 则开着一列货运火车，声称他正在给这辆火车加装机翼，但与此同时，这列火车将仍在铁轨上行驶。由于这个精明的商业决策，比起 Alice，Bob 在早期拥有巨大的商业优势，因为客户会因为他用「飞机 」运输货物而付钱给他。这个有些荒谬的例子想要表达的观点是：即使商业航空有任何独特的附加价值，其在航空发展初期也并不明确（同理，如今在 STARK 和有效性证明方面的附加价值也仍不明确）。最终技术商业变现的唯一方法是遵循 Alice 的路径。

大规模应用的滩头阵地 ：区块链的大规模应用尚未开始，将所有加密货币的总 TPS（每秒交易量）以及 TVL 与传统金融的相应数据进行对比，或衡量人们在日常消费交易（比如常说的一杯咖啡）中使用加密货币的比例，都可以清楚地看出这一点。我们正在构建面向全球规模的加密技术，我们相信我们的技术，即 STARK 证明以及由 Cairo 和 Starknet 提供的可扩展性和安全性，对于区块链的大规模应用至关重要。因为它可以在不降低安全性和不增加信任假设的情况下进行大规模扩展。专注于为这种情景构建正确的技术，我们就不能妥协于那些目前看似「足够好」但在大规模使用压力下会崩溃的解决方案。类比来说，为高速公路建一座桥比为单行道建一座桥更难，而且需要更长的时间才能建成。但当巨大的交通流到来时，人们使用的将是更坚固的桥梁。

我们如何守卫自己走过的捷径？在去中心化和安全性方面，我们不得不做出一些妥协。特别是，我们起初采用了单一的中心化排序器/证明器，并且系统升级是中心化管理的。在极端情况下，这些选择也可能导致灾难性的故障。如果所有项目在开发技术时都在走某些捷径，那么是什么让一种捷径（比如我们正在走的这种）比另一个团队走的捷径更具优势呢？

我想给出两个回答。首先，相比于直接在核心技术做出妥协来说，避免在构成技术核心主张的引擎和动力源方面做出妥协会比较好。当制造一架坚固的商用飞机时，你不应该在其飞行能力上做出妥协，但可以在诸如实现夜间飞行或恶劣天气飞行的能力方面做出一定的妥协。

第二个回答是，只要坚定不移地推广核心技术，就更有可能去掉早期项目中普遍使用的「辅助轮」。对于 Starknet 来说，这意味着我们相信，将中心化系统的排序器和证明器去中心化，要比在本不支持 STARK 证明的系统中添加 STARK 证明来得更容易。

当然，我们的推理也可能是错误的，许多拥有伟大愿景和清晰价值观的公司也因种种原因失败了。这篇简短的文章的重点是为大家阐述，在当前这个早期阶段，我们是如何思考我们所做的技术和商业选择的。