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
I use the helpers to create my config files, which have this setup:
consensus_public_key = "1532a25e2481623938ab6dc001988851d32056e3b0b6bb3c3db870f19048b37d"
consensus_secret_key = "/config/consensus.key.toml"
external_address = "node2.abc.com:2000"
listen_address = "0.0.0.0:2000"
service_public_key = "31169e28fb3dc29e65ae8825dff635bb06be459fafe88cf128443bdbe4633fa0"
service_secret_key = "/config/service.key.toml"
[api]
private_api_address = "0.0.0.0:8010"
public_api_address = "0.0.0.0:8000"
state_update_timeout = 10000
[[connect_list.peers]]
address = "node4.abc.com:2000"
public_key = "0f20ad34a3ee830a323a07e3f6bb51a8030c72e72fc7caadae21df349f4a207e"
[[connect_list.peers]]
address = "node3.abc.com:2000"
public_key = "30ce1435d6175f085beda1027cc6189cef9af65eebbae8c8c6dbc42ff8a79627"
[[connect_list.peers]]
address = "node1.abc.com:2000"
public_key = "c08cd95a8d9c3ac1737b4d835d0e8c77cc57ca9665cad990944cdc18c34bb1c5"This is the config for node2.abc.com, of a 4 node network that includes node1.abc.com, node2.abc.com, node3.abc.com, node4.abc.com. All other nodes similarly have 3 peers with listen_address set to 0.0.0.0:2000 and external_address as their FQDN
Hello everyone!
I'm trying to add an auditor node to a running network, and I cannot quite get it right. Can you help with that?
I use the timestamping example as the basis, so it can be used to reproduce the error.
After bringing up 4 validators with launch.sh script, I configure a new node the same as the validators:
./app generate-config config/common.toml config/a --peer-address 127.0.0.1:6335 -n
./app finalize --public-api-address 0.0.0.0:9000 --private-api-address 0.0.0.0:9001 config/a/sec.toml config/a/node.toml --public-configs config/{1,2,3,4}/pub.tomlThat should result in a config for a node that's not in the list of validators, i.e it should act as an auditor (to my understanding)
Then, I start the new node up (with all validators in peer list)
./app run -c config/a/node.toml -d config/a/db --consensus-key-pass pass --service-key-pass passThat's when the strange things start to happen: a lot of errors on every node in the network and connection failures
Validator nodes log: https://pastebin.com/zrsUaKj3
New node log: https://pastebin.com/i1c9U3AM
When you add a context to the error -- you somehow lose the error itself, so I have only seen the context in the logs, not the error itself.
diff --git a/exonum/src/events/noise/wrappers/sodium_wrapper/handshake.rs b/exonum/src/events/noise/wrappers/sodium_wrapper/handshake.rs
index abc53b7c..84466d33 100644
--- a/exonum/src/events/noise/wrappers/sodium_wrapper/handshake.rs
+++ b/exonum/src/events/noise/wrappers/sodium_wrapper/handshake.rs
@@ -172,7 +172,7 @@ impl Handshake for NoiseHandshake {
.and_then(|(stream, handshake)| handshake.read_handshake_msg(stream))
.and_then(|(stream, handshake, message)| handshake.finalize(stream, message))
.map_err(move |e| {
- e.context(format!("peer {} disconnected", peer_address))
+ failure::format_err!("peer {} disconnected: {}", peer_address, e)
.into()
});
Box::new(framed)
@@ -195,7 +195,7 @@ impl Handshake for NoiseHandshake {
})
.and_then(|((stream, handshake), message)| handshake.finalize(stream, message))
.map_err(move |e| {
- e.context(format!("peer {} disconnected", peer_address))
+ failure::format_err!("peer {} disconnected: {}", peer_address, e)
.into()
});
Box::new(framed)
tx_pool_size (which seems to be at 0 at all times during my testing) and having trouble finding how this would be done.
tx_count grows steadily, but after a few minutes tx_count stops growing even though I am throwing transactions at it constantly. At this point I would expect (maybe?) to see tx_pool_size grow beyond 0 but it stays there and then the requests to grab transaction information start to time out (they have a 30s timeout).
[mempool]
tx_pool_capacity = 5000 in my node config but it didn't seem to change anything
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.