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
dependabot[bot] on npm_and_yarn
dependabot[bot] on npm_and_yarn
Bump node-fetch from 2.6.1 to 2… (compare)
dependabot[bot] on npm_and_yarn
Bump ansi-regex from 3.0.0 to 3… (compare)
dependabot[bot] on cargo
Update protobuf requirement fro… (compare)
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!
Hi @vimmerru! Could you provide more details about your use case? In general, it is impossible to add transactions to the genesis block since at the time the genesis block is created, no services are active, hence there is nothing that can process transactions. The genesis block can only contain instructions to deploy artifacts / instantiate services, which you could view as transactions in some sense; however, this abstraction is not precise (e.g., these "transactions" do not have digital signatures).
Here's a couple of potential alternatives: (a)add transactions to a successive block, not the genesis one; (b) execute logic, which corresponds to transaction, in the constructor of relevant service; (c) execute logic in before_transactions
/ after_transactions
service hooks (e.g., one can check that the blockchain height equals 1 or that the logic was not executed before).
Hi, @flowcietytim ,
Thanks for the report and investigation!
Do I understand correctly that the issue you face occurs with an installed sodium (i.e., not with the one bundled with the lazysodium library)? Could you possibly set system property jna.debug_load=true
and pass JVM option -verbose:jni
to validate that?
We bumped into an issue with similar symptoms with the bundled sodium when enabled parallel builds, but that was resolved quite some time ago.
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.)?
It must be possible on Linux and Mac; on Windows we cannot tell definitely as we don’t currently test on Windows. If it does not work on Windows — that’s certainly a bug. If you have any details on how to reproduce it (incl. JNA logs, the environment, e.g., whether there is an installed sodium library) — please send us an issue.
Also, we are working on proper Windows support (incl. testing Java services on Windows with Testkit; CI for Windows), but that will come later.
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?
Hopefully, next week. That readme was updated prematurely, we usually modify it in a separate pre-release branch :-)
Hi @flowcietytim ,
Thanks for the info!
If the system library is used, then it seems the JNA determines the open flags for LoadLibraryEx
on itself (the default are here). I haven't found though any flags that will prevent read-only loading of the DLL.
We will try to reproduce the issue when we get the main test suite up and running on Windows.
While we all stay in-in at home, Exonum Java 0.10 is out-out! :tada:
It is based on Exonum 1.0, and comes with numerous improvements to dynamic services, service API, and full proof support. See the release page for details, migration guide and a new tutorial on Java service development.
We've also released a Java Light Client 0.6.0, compatible with Exonum 1.0.
How is it possible to modify data of one service from another service?
In Exonum 0.10.3 it was possible like this:
fn execute(&self, mut context: TransactionContext),..
{
let mut schema = OtherSchema::new(context.fork());
Even now it is possible to compile construction:
fn method(&self, context: ExecutionContext<'_>,...
{
let mut schema = OtherSchema::new(context.service_data());
but this approach doesn't work for exonum v1.0.0-rc.1: obtained schema is empty.
Hi Guys,
Just a quick question on the example cryptocurrency-advanced.
Running from the Web, I transferred to a public key:195b5417bee1a8e0c8853615e45c04900f76ad0e7cc58a24903c6882e7e33e46
as the recipient, from a sender public key of 84bccb128bd0940c91aca904910219518686c17779f2b9608dd0be8fdfaa1686
I can see the funds are sent, but in the log, it showed a different to
address.
{
"to": "42f5db7395f22d8649f4e66ef4daeef92750de519fff049fd206decd6dbc966f",
"amount": 100,
"seed": 757009448632885400,
"hash": "04bcf3666b1753ef4a168f01be50c0d94a65d33167912031a60f74aa009dbd39"
}
Is this intended?
And when I run from a ProtocolBuffer, I got
"status": {
"type": "service_error",
"description": "Receiver doesn't exist.\n\nCan be emitted by `Transfer` or `Issue`.",
"code": 2,
"runtime_id": 0,
"call_site": {
"instance_id": 3,
"call_type": "method",
"method_id": 0
}
},
Hopefully, somebody can explain me on the missing receiver. I'm still using the same sender and receiver as per above, which is ok on the Web.
I'm doing this directly from Flutter/Dart using ProtocolBuffer
, as Dart language is not fully supported as official client.
For example, the issue funds works as intended. I can reload, create wallet and all. Here's the code:
/// Issue funds, or reload with the [amount] is the amount to be reloaded
/// signed with the sender's [KeyPair]
///
SignedMessage signIssueFunds(String amount, NaCl.KeyPair keyPair) {
assert(amount.isNotEmpty);
/// Prepare the [Issue] with [amount] and [seed]
///
Issue issue = Issue()
..amount = Int64.parseInt(amount)
..seed = _getSeed();
/// Return a signed message for [methodId], [arguments], and [KeyPair]
///
return _signGeneratedMessage(TX_ISSUE_ID, issue.writeToBuffer(), keyPair);
}
But the transfer didn't work as it says missing recipient key as mentioned above. The code below follows exactly the data needed in the ProtocolBuffer
generated files. Otherwise, I cannot get the error response from Exonum node. Here's the gist of the code
SignedMessage signTransferFunds(
Uint8List to, String amount, NaCl.KeyPair keyPair) {
assert(to.isNotEmpty);
assert(amount.isNotEmpty);
/// Prepare the [Transfer] with, [to], [amount], and [seed]
///
Transfer transfer = Transfer()
..to = (Hash()..data = to)
..amount = Int64.parseInt(amount)
..seed = _getSeed();
/// Return a signed message for [methodId], [arguments], and [KeyPair]
///
return _signGeneratedMessage(
TX_TRANSFER_ID, transfer.writeToBuffer(), keyPair);
}
Anybody can point me to the right direction?
Thanks in advance.
Hi there, i am currently working on building an own application based on the CryptocurrencyAdvanced Tutorial. But whenever i call Exonum.sign() in js light client, i get a signature 128 Bytes in length, instead of the expected 64Bytes (which is ED25519 standard and also the result i get on Java light client).
This is (at least i think it is) the reason for Exonum rejecting my Transactions with "Malformed arguments for calling a service interface method: Wrong Signature size".
Is there anything to keep in mind when calling Exonum.sign() in Javascript light client?
Some more Details on what i am doing:
var messageBytes = MyProtoMessage.encode(myMessage).finish()
var signature = { data: Exonum.sign(keypair.secretKey, messageBytes) }
console.log('signature: ', signature.data.length) //gives me signature: 128
Thanks in advance for any help!
Hello @mhishami.
I can see the funds are sent, but in the log, it showed a different to address.
Because it displays CallerAddress
rather than PublicKey
. Take a look here https://docs.rs/exonum/1.0.0/exonum/runtime/struct.CallerAddress.html
Hi, is there a way to integrate the [explorer websocket(https://docs.rs/exonum-explorer-service/1.0.0-rc.1/exonum_explorer_service/api/websocket/index.html) with java light client? The crate doc obviously only shows rust usage, but i cannot find anything regarding that in the java light client doc and neither did i fiend the corresponding classes in exonum-java.
In a semi-related second question: Is it planned to expand the subscription-functionality of the explorer api/ws? The TransactionFilter feels like a first step, but more filters for transactions and also for blocks would be quite nice (e.g. only blocks containing transaction with hash x, only transactions with status y etc.). Changes in system configuration and more events might be interesting for clients, too.
Thanks in advance!
The Exonum framework is oriented towards creating permissioned blockchains, that is, blockchains with the known set of blockchain infrastructure providers.
, does oriented mean "only" ? Ty you very much.
Hi! I have a source code of a voting system built with Exonum. The voting system has some custom service configuration.
Here is how the configuration is done: https://github.com/PeterZhizhin/blockchain-voting_2021_extracted/blob/main/blockchain/dit-blockchain-source/services/votings-service/src/service.rs#L56-L76
The config protobuf is defined here: https://github.com/PeterZhizhin/blockchain-voting_2021_extracted/blob/main/blockchain/dit-blockchain-source/services/votings-service/src/proto/config.proto#L5-L7
I am unable to provide the public keys via the config. I've tried specifying the public_api_keys
in the template.toml
and in the node.toml
in the following way:
[services_configs.votings_service]
public_api_keys=["0bc1ee47e737e2884e035e3ebf6d5c2516667d5336a6e5af4f1e1c3c1b4f92c4"]
It didn't work. I've tried using the python -m exonum_launcher
, but the voting service doesn't provide service.proto
file and fails with the following error:
ModuleNotFoundError: No module named 'exonum_modules.dit_votings_service_1_0_0.service_pb2'
How do I configure the public_api_keys