I'm playing around with Corda Tokens SDK and trying to figure out how to get the balance of an issued token.
In terminal of PartyA:
I created a new token: start CreateExampleEvolvableToken data: NEW_TOKEN
I issued that token to PartyB: start ExampleFlowWithEvolvableToken evolvableTokenId: 96e57632-2070-4720-ba37-dea61e7c7557, amount: 100, recipient: PartyB
In terminal of PartyB:
If I run run vaultQuery contractStateType: com.template.states.ExampleEvolvableTokenType, I get the token type state; not the balance.
So my question is, what command gives me the information: PartyB has 100 of NEW_TOKEN?
All tokens in Corda are issued as FungibleToken or NonFungileToken, these are modeled as states in Corda. So you could do a simple vaultQuery to fetch the states, use a filter if you want a specific token. There is no amount property for NonFungibleToken since it is unique and only one issued type can exist. FungibleToken has an amount property which would represent the amount of the token held by a party.
Learn more amount Corda Token SDK here:
https://medium.com/corda/introduction-to-token-sdk-in-corda-9b4dbcf71025
Related
There is a dev-network in my project which is including Accounts-sdk, Token-sdk. The project is about transfer of custom tokens between accounts of same node as well as different node. The network is suddenly not notarising the transition which was working for a long time. Now I am not able to transfer the tokens and I am able to transfer the token if I issue the fresh token and transfer. After two or three transactions of transfer the network is again not notarising the transaction.
Throwing
java.util.concurrent.ExecutionException: net.corda.core.flows.NotaryException: Unable to notarise transaction AD57C34EA40953561B90C5EB832336E4E42CD2C876CA5030C986B9EB50909AE7 : One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details: today at 1:05:43 PM14BBC38DF7BDA1FD6CA8E97DB16967FBFC9B18AB95DCD7B1990892C206759FA3(1) -> StateConsumptionDetails(hashOfTransactionId=6190DA0ABAD95B767AB42351368A1D51FCCE164DD08D256F98E065F54B6EE789, type=INPUT_STATE). today at 1:05:43 PMTo find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command.] with root cause today at 1:05:43 PM net.corda.core.flows.NotaryException: Unable to notarise transaction AD57C34EA40953561B90C5EB832336E4E42CD2C876CA5030C986B9EB50909AE7 : One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details: today at 1:05:43 PM14BBC38DF7BDA1FD6CA8E97DB16967FBFC9B18AB95DCD7B1990892C206759FA3(1) -> StateConsumptionDetails(hashOfTransactionId=6190DA0ABAD95B767AB42351368A1D51FCCE164DD08D256F98E065F54B6EE789, type=INPUT_STATE). today at 1:05:43 PMTo find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command.
I am not able to understand why the transfer of token is not been notarised.
Why the network went un-notarising the transfer tokens transaction?
how can I resolve the problem?
It looks like the transaction used to transfer the token is using an input reference that has already been consumed. You can see the transaction id and the output index that is creating the problem in the error description, which could be of some help to debug the issue.
I need to check how the notary prevents the double spending in the Obligation Cordapp. I started the web server UI at the localhost ports and performed some multiple transactions and when I checked the notary's log ,I found this:
[WARN ] 2020-06-24T08:29:33,484Z [Notary request queue processor] transactions.PersistentUniquenessProvider. - Unable to notarise: One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details:
7CF1BCA8EDF25F0602BBEDF8AD41FD60336F65EAC09C5326478A4CB7CD620579(0) -> StateConsumptionDetails(hashOfTransactionId=46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E, type=INPUT_STATE).
To find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command. [errorCode=1g4005y, moreInformationAt=https://errors.corda.net/OS/4.5-RC02/1g4005y]
net.corda.core.internal.notary.NotaryInternalException: Unable to notarise: One or more input states or referenced states have already been used as input states in other transactions. Conflicting state count: 1, consumption details:
7CF1BCA8EDF25F0602BBEDF8AD41FD60336F65EAC09C5326478A4CB7CD620579(0) -> StateConsumptionDetails(hashOfTransactionId=46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E, type=INPUT_STATE).
To find out if any of the conflicting transactions have been generated by this node you can use the hashLookup Corda shell command.
I performed hashLookup on the invalid txId and found this :
hashLookup 46552C5CE153712B65585A75C4D165CD4A05304564C8797ACEF317DCD925B72E
Found a matching transaction with Id: A86E3ECE4EC12A487E413E2BDAB9D88BFEBCB418FA0224189DE0C72BBBD34B12
I believe this is how notary has stopped the double spending. But I am unable to recreate that testing.Can someone tell me what possible input transaction has led to this error.I mean what test case can lead to this testing of double spend that is stopped by notary?
A notary is a network service that provides uniqueness consensus by attesting that, for a given transaction, it has not already signed other transactions that consumes any of the proposed transaction’s input states.
In other words, the notary will keep track of all the input states (only stores their hashes, not the real state) that are used in transactions, so when someone is trying to use these already-spent inputs, the notary will reject the transaction.
Hence, preventing the double spend.
While upgrading from Corda 3 to Corda 4, I have an issue commiting a State to our node's ledger with only one Party. A single Party is able to create a state, notarize it, but CANNOT commit to the Corda 4 ledger without asking for an external third party.
The error Corda 4 produces (which Corda 3 did not produce) is the following:
(1) java.lang.IllegalArgumentException: A flow session for each external participant to the transaction must be provided. If you wish to continue using this insecure API then specify a target platform version of less than 4 for your CorDapp.
More specific context: Using FinalityFlow without a session yields a 'session required for external parties' error and does not complete. Adding only a session (e.g. session = initiateFlow(PartyA) ) results in an error that 'local nodes should not be included.'
Is there a workaround regarding this solution? It's important (for our use case) that a single Party can create a State and modify the State information without the involvement of other parties. Other use cases (where multiple parties are included) stem from this use case. Any guidance is greatly appreciated.
I think the error message is pretty spot on here. Just change the way you call FinalityFlow during your issuance such that it doesn’t contain a flow session to itself i.e.
return subFlow(new FinalityFlow(signedTransaction));
Although you may get a deprecation warning, in which case, do the following
return subFlow(FinalityFlow(stx, emptyList()))
i am getting this error in corda 4 Flow sessions were not provided for the following transaction participants I don't want this participant to sign my transaction then why I got this error?
I have two parties defined in my state class and I want only one of them of to sign the transaction, and I didn't created the flow session for the other party.
Please help to resolve this.
In Corda 4, you are required to pass FinalityFlow a list of sessions that includes all of the transaction's participants, so that the transaction can be distributed accordingly.
Just because someone is in this list of participants, it does not make them a required signer. The required signers are determined by the public keys listed on the transaction's commands.
We have a use case which requires the following steps:
(1) Initiator triggers the transaction flow through UI
(2) The flow is initiated, signed by the initiator and sent to recipient for his verification and signatures (in Corda)
(3) The initiator's flow should get suspended until the recipient validates the transaction by verifying the contract code and submits "verified" again through the UI
(4) This should restart the initiator's flow and the remaining process should be followed as expected in Corda
It was mentioned a few weeks back that user interaction is not yet supported in Corda; is this feature still not present? In the future, we may even want to add the state's attributes through a UI since it gives us the flexibility to propose a transaction we want rather than have it hard-coded. Any idea if this could be possible in future releases?
See the Negotiation Cordapp sample for an example of how this would work in practice here.
Suspending a flow for human interaction isn't currently implemented (as of Corda V3.0).
Instead, you'd implement this by adding a status flag to your state:
class FooState(
override val participants: List<Party>,
val accepted: Boolean) : ContractState
You'd have three commands:
interface Commands : CommandData {
class Propose : Commands
class Reject: Commands
class Accept: Commands
}
And two flows:
A proposal flow: In this flow, the initiator creates and signs a Propose transaction to issue the state onto the ledger with a Propose command and the accepted flag set to false
An accept flow: In this flow, the recipient either:
Creates a Reject transaction that consumes the proposed state and outputs nothing. The state has been removed from the ledger and is effectively rejected
Creates an Accept transaction that updates the proposed state so that accepted is true. The state has now been accepted, and this fact is registered on the ledger
You'd give the accept flow a parameter which determines whether or not to accept the proposal. This parameter would be provided by the user when the flow is kicked off either via an API or directly over RPC.