Exonum is an extensible open-source framework for creating blockchain applications. Github: https://github.com/exonum/ Documentation: https://exonum.com/doc/ Russian-speaking community https://gitter.im/exonum/ruExonum Telegram channel: https://t.me/exonum_blockchain
All i am doing is creating the transaction (protobuf builder), building a signed TransactionMessage and then using 'exonumClient.submitTransaction(transactionMessage)' to send it.
I am able to pull the authorKey out of the message and verify the signature, so it seems to be a configuration issue in the node.
However, my colleague was able to send a test transaction from within rust, so the basic functionality is given.
Thanks in advance!
Hi, i've got a question regarding the Transaction Lifecycle and its implementation. My question is based on the transaction-documentation
We implemented a custom service based on the cryptocurrency advanced tutorial.
Our goal is to submit some payload ("contract") via light client and create an ID in the backend. According to my understanding of the afformentioned document chapter, the right moment to do so is the execute(), because
"The results of execution are reflected in Precommit consensus messages and are agreed upon within the consensus algorithm. This ensures that transactions are executed in the same way on all nodes."
We implement that by calling schema.create_contract() during execute().
However, this leads to every node creating its' own id and therefore an incosistent state of the network.
The documentation also reads
All transactions from the committed block are sequentially applied to the persistent blockchain state by invoking their execute method in the same order the transactions appear in the block.
During the Commitment Phase.
So: what are we doing wrong? Is there a way to enrich the submitted message with additional data during Verification/Broadcasting/Consensus phase of lifecycle? What is executed during Consensus and what during commitment?
Thanks in advance!
Hi @flowcietytim ,
Does your transaction assign the IDs in deterministic fashion based only on the current database state and the transaction arguments? If this condition is met, the transactions must produce the same result on different nodes, as they are executed in the same order, determinned by the consensus algorithm beforehand. If the transaction uses some other state which is not controlled by Exonum (e.g., local RNGs) to modify the database, it may lead to different results on different nodes.
Hi @badadin ,
If you need a network with any service (i.e., you don't need to test service-specific operations, like submitTransaction, expecting transaction parameters specific to a certain service), you can launch the cryptocurrency-advanced with Docker: https://github.com/exonum/exonum/tree/v0.13.0-rc.2/examples/cryptocurrency-advanced
Please mind the Light Client compatibility matrix: https://github.com/exonum/exonum-java-binding/tree/master/exonum-light-client#compatibility
— the latest version is compatible with 0.13.0, but we are working on getting a 1.0.0-compatible release.
exonum-merkledb crate and transaction generation from the exonum crate and implement client functionality this way - we've done this in some internal projects.
Hi @flowcietytim ,
I am not really a JS expert, so can only suggest to look into how cryptocurrency-advanced frontend deals with field of long type: https://github.com/exonum/exonum/blob/v1.0.0-rc.1/examples/cryptocurrency-advanced/frontend/src/plugins/blockchain.js#L78
uint64 is used in most transactions of that service: https://github.com/exonum/exonum/blob/v1.0.0-rc.1/examples/cryptocurrency-advanced/backend/src/proto/service.proto#L22
Hi @dmitry-timofeev, thanks for your response. I've build my own service based on the crypto-advanced and used basically the same methods. I've compared code several times, thats why i'm asking for help here. Do you have any experience with that special error ("unexpected wire type")? Can you confirm that this is a protobuf-related problem?
I now have rebuild the transaction creation in java light client and am getting the exactly same problem.
This strongly points me in the backends' direction.
What's baffeling me is that i get the same error no matter which transactionID i'm using. Could this be a hint on what is happening?
I am suspecting there is some problem in the overall transaction message structure, not the payload itself.
Hi @flowcietytim ,
It looks like a protobuf error indeed.
Would you share please:
- The Exonum runtime version which your service uses.
- The Java light client version. Please note the 1.0.0-rc1 compatible JLC is not yet released. Using the previous version with 1.0.0-rc1 will lead to protobuf or other errors.
1.0.0-rc1 compatible JLC can be built locally, if needed (you don't need to install anything but Java and libsodium to build the JLC, andgit submodule update --init). - The protobuf message for transaction arguments.
- The code creating and sending the transaction.
the description on the Github Example Page is a good starting point, but is based on the
cargo install --path . command, which is not that obvious and leads to the code happily running from global instead of local install.Maybe switching it to
cargo install --path ./target and then ./target/exonum-cryptocurrency-advanced generate-config might be an improvement. This would throw an error if one would install it globally by mistake, making it more obvious if the wrong code is being used.
Hi @flowcietytim ,
We plan to release the second and, hopefully, the last 1.0.0 release candidate next week (1.0.0-rc.2). It must be very close to 1.0.0, we don't plan any changes but bug fixes. 1.0.0 will come after the integration of the rc2 into other projects in the ecosystem (various client libraries and tools, Java runtime, etc.), which is likely to take several weeks. Therefore, if you take the rc2, the service code is unlikely to require any changes when upgrading to 1.0.0, but you might find some pieces missing till 1.0.0 (e.g., a released launcher).
@askolesov ,
Can groups be used for it?
Possibly, if it makes sense to keep all entries with a certain prefix in a separate ProofMapIndex (i.e., if you don't need to make queries by prefixes of arbitrary size). Then you could provide a multiproof for all entries in a ProofMapIndex for the given prefix, using get_multiproof. However, you will have to aggregate the state hashes of each ProofMap in the group in another regular ProofMap, so that their state hashes affect the blockchain state hash recorded in the block. That is needed because MerkleDB aggregates state hashes of non-grouped (regular) Proof* indexes by default.
get_multiproof won't work: that will prove that some keys (that the service decided to include) are present, but will not prove to the client that these keys are all that have a certain prefix.
Hi, while connecting our java-backend to exonum via exonum-java light client, i've run in a roadblock when running multiple instances of the light client on the same machine. When creating a keypair, the application seems to lock libsodium.dll (on windows) and never let go of this. So the second instance is not able to access it and throws an error.
From what i can find terl/lazysodium-java#53, this is fixed from 4.1.0 of lazysodium onwards and with current version of light client (0.5.0) exonum-java-binding-common 0.9.0-rc2 is used, which depends on lazysodium 4.2.3
I now have 3 questions:
1) could somebody please confirm, that with current/upcoming java light clients it is possible to have multiple java applications running on the same host and utilizing Crypto functions (keyPair generation, signing etc.)?
2) java light client gitbhub page references 0.6.0 as Version for Exonum 1.0 but is not yet available (at least not as release and/or on maven central). Is there a plan when this will be released?
3) The maven central button on java light client readme page is not working (in contrast to that on java binding, which links to maven central repository). Just a hint, a fix would be helpful for github research :)
Thanks a lot in advance!
