以太坊智能合约。我可以屏蔽/隐藏 Contract Creator 地址吗？如果可以，我需要这样做吗？
Ethereum Smart Contracts. Could I mask / hide the Contract Creator address and if so, do I need to?
我是一名产品经理，不是区块链编码员，正在寻找第二意见和一些一般性的良好实践建议。我有一个粗体问题，其余是背景。
背景：
- 我们正在开发一个应用程序，可以将用户信息写入 ETH 区块链上的智能合约。
- 我们部署的 SC 仅包含信息，不包含以太币。
- 每个用户都有自己的 SC，它只存储该用户的特定信息。
- 我们的应用程序允许用户编辑和更新此信息，然后将更改内容加密上传到他们自己的 SC 中。
- 用户的 SC 地址 'tied'（抱歉，术语不正确）到他们自己的以太钱包。
- 我在 Etherscan (Ropsten) 上看到有一个 Contract Creator 地址，它是我们应用程序创建的所有 SC 的常量。
- 我假设合约创建者地址对我们来说是唯一的，它是我们创建的代码，因此它仅代表我们的应用程序部署我们的智能合约。
- 我希望每个 SC 地址只为它的所有者和我们所知。现在我看到任何人都可以访问此信息。
我的问题：
如果我们的代码中存在可利用的缺陷，那么坏人就会有一个合约地址列表来攻击。
对我们来说最坏的风险是，如果我们的可公开访问的代码中存在缺陷，坏人可以访问未加密状态的每个用户数据。
坏人然后利用该漏洞和他们可以从 Etherscan 获得的智能合约地址列表来下载多个用户数据。
我的问题
这些担忧是否现实？
- 如果是这样，我们可以考虑哪些总体方向来减轻这些风险
- 如果是这样，我可以在 Etherscan 中隐藏创建者地址而不会产生其他负面后果
开发人员是外包的第 3 方和优秀的合作伙伴。但我正在寻找替代意见，而不仅仅是他们的意见，作为双重检查。
如果我提供的信息令人困惑或不完整，我们深表歉意。
提前感谢您的宝贵时间。
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
正如您在此处提到的，有关区块链的数据（即交易哈希、合约地址和用户地址）是透明可用的。这是以太坊的设计使然，并允许分类帐的可追溯性方面。
此外，智能合约数据 可能 可供以太坊网络中的任何参与者使用。但是，这是基于以下内容：
- 为了访问智能合约数据，参与者需要合约 ABI。该接口允许编写代码以与智能合约方法进行交互。现在，理解这个 ABI 可以很容易地反向生成是有帮助的，其中包含关于您的 DApp 如何与现有智能合约交互的足够详细信息。
- 如果您的智能合约逻辑存在可利用的缺陷，网络上的恶意行为者可能会利用这一点。这就是为什么合约应该写得很好并且单元测试接近（如果不是）100% 的代码覆盖率。您还应该确定每个合同场景中的潜在参与者，并确保您的测试用例适当地涵盖这些场景。
If so what general directions can we look at to mitigate these risks
鉴于您所描述的合同场景，如果 只有 应该有权访问这些用户数据智能合同的参与者是他们自己，那么您只需要应用一些东西类似于智能合约逻辑的 function modifier。在链接示例中，对智能合约数据的访问仅限于单个特定的以太坊用户地址。
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
当然可以。听起来您目前正在使用单个帐户来部署智能合约，因此创建者地址是不变的。 （旁注：我不确定您为什么要使用此帐户代表用户部署合同，听起来用户应该部署自己的智能合同）。无论如何，您可以在每次部署智能合约时简单地创建一个新的代理用户地址。但是，我认为这样做没有任何好处，这只是 security through obscurity.
的一个示例
我是一名产品经理，不是区块链编码员，正在寻找第二意见和一些一般性的良好实践建议。我有一个粗体问题，其余是背景。
背景：
- 我们正在开发一个应用程序，可以将用户信息写入 ETH 区块链上的智能合约。
- 我们部署的 SC 仅包含信息，不包含以太币。
- 每个用户都有自己的 SC，它只存储该用户的特定信息。
- 我们的应用程序允许用户编辑和更新此信息，然后将更改内容加密上传到他们自己的 SC 中。
- 用户的 SC 地址 'tied'（抱歉，术语不正确）到他们自己的以太钱包。
- 我在 Etherscan (Ropsten) 上看到有一个 Contract Creator 地址，它是我们应用程序创建的所有 SC 的常量。
- 我假设合约创建者地址对我们来说是唯一的，它是我们创建的代码，因此它仅代表我们的应用程序部署我们的智能合约。
- 我希望每个 SC 地址只为它的所有者和我们所知。现在我看到任何人都可以访问此信息。
我的问题：
如果我们的代码中存在可利用的缺陷，那么坏人就会有一个合约地址列表来攻击。
对我们来说最坏的风险是，如果我们的可公开访问的代码中存在缺陷，坏人可以访问未加密状态的每个用户数据。
坏人然后利用该漏洞和他们可以从 Etherscan 获得的智能合约地址列表来下载多个用户数据。
我的问题
这些担忧是否现实？
- 如果是这样，我们可以考虑哪些总体方向来减轻这些风险
- 如果是这样，我可以在 Etherscan 中隐藏创建者地址而不会产生其他负面后果
开发人员是外包的第 3 方和优秀的合作伙伴。但我正在寻找替代意见，而不仅仅是他们的意见，作为双重检查。
如果我提供的信息令人困惑或不完整，我们深表歉意。
提前感谢您的宝贵时间。
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
正如您在此处提到的，有关区块链的数据（即交易哈希、合约地址和用户地址）是透明可用的。这是以太坊的设计使然，并允许分类帐的可追溯性方面。
此外，智能合约数据 可能 可供以太坊网络中的任何参与者使用。但是，这是基于以下内容：
- 为了访问智能合约数据，参与者需要合约 ABI。该接口允许编写代码以与智能合约方法进行交互。现在，理解这个 ABI 可以很容易地反向生成是有帮助的，其中包含关于您的 DApp 如何与现有智能合约交互的足够详细信息。
- 如果您的智能合约逻辑存在可利用的缺陷，网络上的恶意行为者可能会利用这一点。这就是为什么合约应该写得很好并且单元测试接近（如果不是）100% 的代码覆盖率。您还应该确定每个合同场景中的潜在参与者，并确保您的测试用例适当地涵盖这些场景。
If so what general directions can we look at to mitigate these risks
鉴于您所描述的合同场景，如果 只有 应该有权访问这些用户数据智能合同的参与者是他们自己，那么您只需要应用一些东西类似于智能合约逻辑的 function modifier。在链接示例中，对智能合约数据的访问仅限于单个特定的以太坊用户地址。
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
当然可以。听起来您目前正在使用单个帐户来部署智能合约，因此创建者地址是不变的。 （旁注：我不确定您为什么要使用此帐户代表用户部署合同，听起来用户应该部署自己的智能合同）。无论如何，您可以在每次部署智能合约时简单地创建一个新的代理用户地址。但是，我认为这样做没有任何好处，这只是 security through obscurity.
的一个示例