解读可升级智能合约的困境

嘿，各位 👋🏻

欢迎来到另一篇关于可升级智能合约这一经典难题的快速文章：

🔴 我们是否应该考虑可升级的智能合约？

🔴 将智能合约保持得尽可能简单不是更安全吗？额外的复杂性意味着更多的错误，对吗？

🔴 但是，我们如何安全地开发可升级的智能合约？如果我们遇到诸如存储冲突或不充分的升级之类的问题怎么办？

🔴 即使我们开发了，我们应该如何安全地升级它们？

…..

正是这些问题或困惑使我们无法为智能合约选择可升级的功能。

几天前我也参与了类似的讨论，因此写了这篇快速文章，以消除围绕可升级智能合约的一些难题。

🤔 Dev 1 想要开始开发他的智能合约，但他非常困惑是否应该使其可升级。

他认为他的智能合约将来可能需要其他功能，这就是为什么可升级合约可能是正确的选择。

但是，考虑到处理可升级合约的复杂性，他不确定是否应该继续进行。

👨‍💻Dev 2: 可升级合约并不是一个真正安全的主意，因为它们可能会给你的合约带来额外的复杂性，并最终导致引入高危漏洞。

这里可能存在一个漏洞，导致存储冲突或不充分的身份验证程序，允许任何人升级，这会使你的资产面临风险。

👩‍💻Dev 3: 如果你不确定你的所有智能合约功能，并且有可能出现新的功能，那么可升级合约是正确的选择。

可升级合约确实可以帮助你修复智能合约中的任何错误，这是不容忽视的。

此外，开发可升级合约实际上并不难，因为我们现在拥有一些真正有效的库和工具，可以确保存储冲突、不安全升级等问题得到解决。

我的想法🧐

⏩ 在智能合约领域，一个众所周知的理论是：应该尽可能保持智能合约的简单性，因为增加复杂性可能会引入新的错误。

在某种程度上，这是非常正确的，因为我们并不真的需要每次都重新发明轮子，智能合约的安全性应该始终是重中之重。

⏩ 然而，智能合约，尽管它们具有处理资金或不可思议的强大功能，但它们也是代码。代码中出现一些错误是不可避免的。

截至目前，可升级合约是我们目前拥有的最有效的工具之一，可以解决这些错误，即使合约已部署（在大多数情况下）。

⏩ 仅仅因为可升级合约可能会增加现有智能合约架构的复杂性而避免使用它们可能不是一个好主意，尤其是当你知道你可能需要一个时。

⏩ 加强我们对可升级智能合约的理解是我们所需要的，并且应该优先考虑，而不是避免它。

⏩ 此外，我相信智能合约升级模式现在已经经历了相当一段旅程，从 Eternal Storage 机制到最近的 Transparent Upgradeable 代理或 UUPS。

观看此视频并享受，非常酷的 Thomas Wiesner ，带领我们了解可升级智能合约的整个过程以及它们如何随着时间的推移而演变。

因此，现在我们有了更安全的合约升级程序，以及 Openzeppelin 提供的令人惊叹的库和工具，这些库和工具简化了整个过程。

查看 OpenZeppelin 在 此处 提供的有关可升级智能合约的宝藏。

⏩ 虽然并非每个合约都需要可升级，但需要可升级的合约应该可升级。

💡但是，对于此类合约，正确的问题不是它们是否应该可升级。

而是 👇

我们应该如何安全地升级智能合约？

🔴 如果你将智能合约的所有可升级能力都集中到一个简单的地址 (EOA) 上，那么这肯定不是一个安全的合约。

🔴 升级此类智能合约的一种安全方法是使用 ProxyAdmin 合约和 Multisig，从而消除对升级的单一权限控制。

🔴 通过链上治理进行升级是另一种安全、有效且去中心化的方式。

\ Solidity ABI编码的深度心理模型：第一部分\ 为什么要学习 Solidity 的难点 [ ABI 编码系列：第 0 部分 ] \ \ Solidity 很简单。\ \ 它是一种简单而美丽的语言。\ \ 随着优秀的教育资源、课程、开发工具和 LLM 的兴起，学习和编写 Solidity 从未如此简单。\ \ 但这里有一个残酷的事实——如果每个人都很容易上手，那么\ 我的第一个 SUI-Move 迷你项目 - 第 2 部分\ 我第一次使用 Move 智能合约 - 第 1 部分 \ \ 最近我尝试了一种新的智能合约语言 MOVE。\ \ 该语言的灵感来自 Rust，因此对于 Solidity 开发人员来说并不直观。\ \ 但是，使用它进行构建非常有趣。\ \ 在本系列文章中，我旨在介绍 Move 语言及其功能。

• 原文链接： decipherclub.com/deciphe...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～