0
votes

I am using accounts in Corda. New accounts are creating successfully in my code but, I am facing difficulties in doing these two things. 1.) How to check if account is actually created and is present in the node, means if we can check the list of all the accounts in Corda.

2.) How to write responder flow for accounts, means My transaction flow is not working properly. Is there anything to change in the responder flow classic code if we now start using the accounts library?

My Code is as follows :

@InitiatedBy(Proposal.class)
public static class ProposalAcceptance extends FlowLogic<Void> {

    //private variable
    private FlowSession counterpartySession;

    //Constructor
    public ProposalAcceptance(FlowSession counterpartySession) {
        this.counterpartySession = counterpartySession;
    }

    @Suspendable
    @Override
    public Void call() throws FlowException {
        SignedTransaction signedTransaction = subFlow(new SignTransactionFlow(counterpartySession) {
            @Suspendable
            @Override
            protected void checkTransaction(SignedTransaction stx) throws FlowException {
                /*
                 * SignTransactionFlow will automatically verify the transaction and its signatures before signing it.
                 * However, just because a transaction is contractually valid doesn’t mean we necessarily want to sign.
                 * What if we don’t want to deal with the counterparty in question, or the value is too high,
                 * or we’re not happy with the transaction’s structure? checkTransaction
                 * allows us to define these additional checks. If any of these conditions are not met,
                 * we will not sign the transaction - even if the transaction and its signatures are contractually valid.
                 * ----------
                 * For this hello-world cordapp, we will not implement any aditional checks.
                 * */
            }
        });
        //Stored the transaction into data base.
        subFlow(new ReceiveFinalityFlow(counterpartySession));
        return null;
    }
}
2

2 Answers

1
votes
  1. Account internally are simply corda states of type AccountInfo, so you could query the vault to list all accounts the node knows about using:

    run vaultQuery contractStateType: com.r3.corda.lib.accounts.contracts.states.AccountInfo

  2. There isn't anything specific that changes in the responder flow, please make sure you are using the correct sessions in the initiator flow. Take a look at few of the samples available in the samples repository here: https://github.com/corda/samples-java/tree/master/Accounts

1
votes
  • To check that an account was created, you need to write flow tests; a great way to learn is to look at how R3 engineers conduct their tests.
  • For instance, you can find here the test scenarios for CreateAccount flow.
  • To get an account, the library has a very useful service KeyManagementBackedAccountService with different methods to get an account (by name, UUID, or PublicKey); have a look here.
  • Now regarding requesting the signature of an account, one thing that is important to understand is that it's not the account that signs the transaction, it's the node that hosts the account that signs on behalf of the account.
  • So let's say you have 3 nodes (A, B, and C); A initiates a flow and requests the signature of 10 accounts (5 are hosted on B, and 5 are hosted on C).
  • After A signs the initial transaction it will create FlowSessions to collect signatures.
  • Since it's the host nodes that sign on behalf of accounts, then in our example you only need 2 FlowSessions; one with node B (so it signs on behalf of the 5 accounts it hosts) and one session with node C (for the other 5 accounts).
  • In the responder flow nodes B and C will receive the transaction that was signed by the initiator.
  • Out of the box, when a node receives a transaction it looks at all of the required signatures and for each required signature if it owns the private key; it will provide that signature.
  • Meaning, when node B will receive the transaction; it will see 10 required signatures, and because it hosts 5 of the accounts (meaning it owns the private keys for those 5 accounts), then it will automatically provide 5 signatures.