Hyperlededger Fabric Composer事务中的权限

时间:2017-11-15 11:05:57

标签: hyperledger-fabric hyperledger hyperledger-composer

我有两个Participants A和B,每个identity都有自己的CA

有一项交易可让一个ParticipantCoins转移到另一个。

participant Person identified by id {
    o String id
    o String firstName
    o String lastName
    o Double coins
}

交易cto文件

transaction TransferCoins {
    o Double coinsTransferred      
    --> Person receiver
    --> Person sender
}

permissions.acl文件

rule PersonCanModifyOnlySelf {
    description: "Allow Persons to modify only their profile"
    participant(p): "org.varun.business.Person"
    operation: READ, UPDATE, DELETE
    resource(r): "org.varun.business.Person"
    condition: (r.getIdentifier() === p.getIdentifier())
    action: ALLOW
}

rule PersonCanReadAllProfile {
    description: "Allow Persons read access to other Persons"
    participant: "org.varun.business.Person"
    operation: READ
    resource: "org.varun.business.Person"
    action: ALLOW
}

transaction.js文件

/**
 * Person to Person transaction
 * @param {org.varun.business.TransferCoins} transferCoins
 * @transaction
 */
function TransferCoins(transferCoins) {

    var coinsToTransfer = transferCoins.coinsTransferred;
    transferCoins.sender.coins = transferCoins.sender.coins - coinsToTransfer;
    transferCoins.receiver.coins = transferCoins.receiver.coins + coinsToTransfer;

    return getParticipantRegistry('org.varun.business.Person')
        .then(registry => {
            return registry.updateAll([transferCoins.sender, transferCoins.receiver]);
        })                
}

简而言之

  • 每个人只能update他们自己的个人资料
  • 每个人都具有通用read访问权限

当调用TransferCoins函数时,从A中减去硬币,同时将硬币添加到B.参与者注册表被调用并更新。

现在如果A打电话给这个交易,我收到一个错误,说A不能更新B的硬币(显然是由于上面定义的acl)。那么这种交易如何运作?有人可以帮帮我。

2 个答案:

答案 0 :(得分:2)

好的问题!

所以我会定义两个交易:

InitiateTransfer {} AcceptTransfer {}

在您的模型中。

参与者A将调用InitiateTransfer(交易功能)。在调用时,您可以在更新后发出事件,例如节点红色事件 - 向电子邮件参与者B发送传入转移,电子邮件中的链接等去接受转移。

参与者B签署申请并接受转移(最终调用AcceptTransfer()交易功能)。

参与者A和参与者B是两个单独的交易,并且不会违反您现有的ACL条件。您是否希望CoinTransfer更新参与者或资产的余额(例如,与参与者有关系的帐户风格,在交易中 - 请参阅下面的***NOTE)完全取决于您。

事务处理器函数将在提交事务之前等待Promises被解析。如果承诺被拒绝,交易将失败。

Composer事务所做的更改是原子的,要么事务(正如您已定义它)成功并应用所有更改,要么事务失败并且不会对该事务应用任何更改。建议还要查看错误处理'在交易没有得到承诺的情况下专门处理错误的文档中。由Fabric或区块链本身(因此,参与者B是否会进行交易) - > https://hyperledger.github.io/composer/reference/js_scripts.html

*****注:*** 你可以(由你决定)想要考虑建立什么样的模型。你提出了在转移后维持平衡(发起者和接受者)的概念 - 这可以被建模为资产(例如,coinAccount),其中ID字段,coinBalance和coinHolder(链接到Person)最低限度。交易由发起人发起并更新其账户(减少coinAccount余额),同样,单独的交易更新接受者coinAccount余额。

答案 1 :(得分:0)

我也看到了资产水平。提交的交易带有一个身份。在您的情况下,参与者A的。如果ACL将他/她限制在自己的记录中,那么该制度使得事务处理器难以在单个区块链事务中实现您想要的。

那么是否可以向一方提交交易,该交易与A或B无关但可以更新两者?这可能是最好的方式。事务历史记录将用于查看提交事务后发生的更改。

如果需要(为了报告或其他目的),也可以将发送者和接收者的配对列表记录和时间戳等记录为同一交易逻辑的一部分。