Limitations intelligentes de contrat dans Ethereum & Fabric

Question

J'essaye de faire un contrat intelligent pour réaliser automatiquement ce qui suit. Mais je me suis coincé dans la mise en œuvre. Comment puis-je exécuter le (2) Tx sans avoir B pour signer le Tx, c'est-à-dire: Je veux qu'il s'exécute automatiquement une fois (1) est activé et la condition (2) est prête.

pseudocode (un):

A send 50 to B  (1) 
if (B > 50)   (2) 
    B send 10 to C (3) 

Le code ci-dessus implique plusieurs propriétaires, à savoir. A, B et C. Premièrement, A active le contrat en exécutant/signant Tx (1). Ensuite, le contrat vérifie la condition (2). Maintenant, mais comment courir (3) automatiquement sans avoir à forcer B à signer?

En fin de compte, le contrat est-il en mesure de signer (ou de signer par procuration) sur le comportement de B?

---

modifier

Qu'en est ci-dessous dans une chaincode? Peut-il fonctionner automatiquement, c'est-à-dire que D doit signer en utilisant la clé privée de D dans (3)?

pseudocode (deux):

A send 50 to B  (1) 
if (something is true, say Z > 50)   (2) 
    D send 10 to F (3) 

Answer 1

En fin de compte, est le contrat en mesure de signer (ou signe proxy) de B sur comportent?

n °

A commence les opérations en envoyant des fonds nécessaires au contrat, et le contrat de fonds selon disperse les règles. Donc, A -> contrat, contrat -> B et éventuellement, contrat -> C.

Bien que ce soit en dehors de la question soulevée, il vous sera peut-être utile d'éviter de refactoriser plus tard pour observer la meilleure pratique de séparer les deux départs si B et/ou C sont des contrats non approuvés. Vous devez simplement procéder à la comptabilisation à l'étape du dépôt, puis utiliser un modèle de retrait lorsque B & C réclame leurs droits (transactions distinctes).

Espérons que ça aide.

Mise à jour:

Voici une esquisse qui pourrait vous donner quelques idées. Je n'étais pas sûr si le> 50 était un total de tous les temps ou un paiement unique> 50. C'est un exemple artificiel qui s'attend à ce que vous passiez deux adresses valides pour B & C afin que le contrat connaisse leurs adresses.

Vous pouvez envoyer des montants à partir de n'importe quelle adresse (A) et le contrat suivra owedToB et owedToC.

Vous devriez être en mesure d'envoyer une transaction à withdraw() de B ou C pour réclamer le solde dû.

Il est un peu long de tout mettre en place pour un test complet afin de présenter "tel quel".

pragma solidity ^0.4.6; 

contract Royalty { 

    address public B; 
    address public C; 
    uint public owedToB; 
    uint public owedToC; 

    event LogPaymentReceived(address sender, uint amount); 
    event LogPaid(address recipient, uint amount); 

    // pass in two addresses, B & C for this simple constructor 

    function Royalty(address addressB, address addressC) { 
    B = addressB; 
    C = addressC; 
    } 

    function pay() 
    public 
    payable 
    returns(bool success) 
    { 
    owedToB += msg.value; 

    // You can do B.balance > 50 but beware how it drops below 50 after withdrawal 
    // A little more involved, but you can have totalReceipts AND totalPayments so owedToB is totalReceipts - totalPayments 
    // It all depends on the business terms you're trying to enforce. 

    if(msg.value > 50) { 
     owedToC += 10; 
     owedToB -= 10; 
    } 

    LogPaymentReceived(msg.sender, msg.value); 
    return true; 
    } 

    function withdraw() 
    public 
    returns(uint amountSent) 
    { 
    if(msg.sender != B && msg.sender != C) throw; // only B & C can withdraw 

    uint amount; 
    if(msg.sender == B) { 
     amount = owedToB; 
     owedToB = 0; 
     if(!B.send(amount)) throw; 
     LogPaid(B,amount); 
     return amount; 
    } 
    if(msg.sender == C) { 
     amount = owedToC; 
     owedToC = 0; 
     if(!C.send(amount)) throw; 
     LogPaid(C,amount); 
     return amount; 
    } 
    // we shouldn't make it this far 
    throw; 
    } 

}