昨天，我刚刚开始使用帐户库进行阅读/实验，并试图将自己的头信包裹在我所在州的参与者/签名者部分。
假设我有以下内容：
1. 薄荷：发行令牌的节点。
2. 注册表：一个托管帐户并在请求时为其生成密钥对的节点。
3. 钱包：一个代表帐户持有令牌的节点。
4.我创建了自己的可替代令牌，该令牌基本上具有一个额外字段：PublicKey owningAccount
过程：
1. 注册表创建了一个新帐户（我们称为 Account001 ），因此注册表是该帐户的host。
2. 薄荷从注册表
请求为 Account001 的新密钥对。
3. 薄荷向 Wallet 发行新令牌，并将 owningAccount 设置为他们为 Account001 从< strong>注册表，所以现在钱包是令牌的holder
现在我们有了：
1. 注册表是帐户001
的host
2. 钱包是令牌的holder（代表 Account001 ）
问题：
1.我拥有这三个节点的方法正确吗？一个节点控制令牌的供应，另一个节点控制用户，最后一个节点跟踪每个用户的令牌“余额”。
2.我想保持节点分离（假设它在概念上是正确的）；出于这个原因，我不想将 owningAccount 作为令牌的参与者的一部分，因此令牌将仅保留在 Wallet的文件库中，但，我将需要 owningAccount 作为各种命令的签名者（例如，将令牌移动到新的 owningAccount 时； holder（即钱包）和所有者（即 owningAccount 的注册表）必须签名）。
3.通常（如果忘记了令牌），如果我有一个管理用户的节点，另一个有管理具有 owningAccount 字段的状态的节点，那么在该状态下，我需要具有 owningAccount < / strong>作为参与者？就像我提到的那样，我仍在尝试找出“正确的”方法（通常，随着我编写更多程序，事情会变得更加清晰），但是我想应该在 owningAccount 只是存在一些脱钩的情况下需要作为与与其相关的状态有关的命令的签名者，参与者主要只是该状态所发布到的节点。
答案 0 :(得分：1)
罗杰·威利斯（Roger Willis）在Slack上向我解释了FungibleToken如何通过使用 Holder 属性将令牌分配给某个所有者（即公钥）而不是一方；过程如下：
1. Mint 节点启动issue token流，该流将输入金额和AccountInfo参考作为
2.它从 Accounts Registry 节点请求新的公钥，用于所引用的AccountInfo
3.接收到的公钥用于获取各自的参与者（即identityService.partyFromKey(receivedPublicKey)）
4.结果方被分配为令牌的持有人
5.请记住，缔约方是CordaX500Name（在我们的情况下是帐户注册中心），并且是标识该实体的公钥（在我们的情况下，是映射到 AccountInfo 状态（即特定用户））。
6.因此，每当我们发行新令牌时，持有人将始终是帐户注册机构，但同一方将为不同的所有者/用户提供不同的公钥。
7.话虽如此，我们不再需要2个节点 Accounts Registry 和 Wallets ，我们将只有1个节点 Wallets ，其中包含我们的 AccountInfo 状态和我们的令牌，其中令牌的持有者是 Wallets 方，但该方中的公钥将有所不同，并根据以下内容映射到不同的 AccountInfo 状态谁是所有者/用户。