by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:50
    Travis exonum/exonum (master) still failing (4766)
  • Aug 03 08:09
    Travis integrer/exonum (master) still failing (32)
  • Aug 03 07:49

    aleksuss on master

    Bump nvm to 12 in Travis CI scr… (compare)

  • Aug 03 07:37

    aleksuss on master

    Update JS dependecies (compare)

  • Aug 03 07:32

    aleksuss on master

    Update JS dependecies (compare)

  • Jul 30 08:10
    Travis exonum/exonum (master) still failing (4765)
  • Jul 30 07:32

    dependabot-preview[bot] on npm_and_yarn

    (compare)

  • Jul 30 07:32

    dependabot-preview[bot] on master

    [Security] Bump elliptic from 6… (compare)

  • Jul 30 07:32
    dependabot-preview[bot] closed #187
  • Jul 30 07:32
    aleksuss commented #187
  • Jul 30 07:32
    aleksuss review_requested #187
  • Jul 30 07:31

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jul 30 07:31
    Travis exonum/exonum (master) canceled (4764)
  • Jul 30 07:31

    aleksuss on master

    Bump elliptic from 6.5.2 to 6.5… (compare)

  • Jul 30 07:31
    aleksuss closed #1883
  • Jul 30 07:31

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jul 30 07:31

    aleksuss on master

    Bump elliptic in /examples/cryp… (compare)

  • Jul 30 07:31
    aleksuss closed #1882
  • Jul 30 01:20
  • Jul 30 01:01
    codecov[bot] commented #1883
Dmitry Timofeev
@dmitry-timofeev

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

flowcietytim
@flowcietytim
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?
flowcietytim
@flowcietytim

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.

Sergey Khoroshavin
@skhoroshavin
@slowli thank you!
Dmitry Timofeev
@dmitry-timofeev

Hi @flowcietytim ,

It looks like a protobuf error indeed.

Would you share please:

  1. The Exonum runtime version which your service uses.
  2. 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, and git submodule update --init).
  3. The protobuf message for transaction arguments.
  4. The code creating and sending the transaction.
JS client for 1.0.0-rc1 has already been released: https://github.com/exonum/exonum-client#light-client-for-exonum-blockchain
Mikhail Milekhin
@mmikhail-git
Hi guys. Is there real evidence that customers are using blockchain anchoring?
It seems that this feature may be useful. But in practice, everything stops when the customer has to lay out real money to buy Bitcoin
flowcietytim
@flowcietytim
Hi @dmitry-timofeev, sorry for the delayed answer. I got it working in the meantime, it was a build error due to a wrong node config, causing npm to build globally and then running nodes from the local build, which then used the old protobuf messages (since the new ones were installed globally). So no error on exomun-side of things.
Dmitry Timofeev
@dmitry-timofeev
Hi @flowcietytim , good you figured that out! If any updates to the docs on the light client are needed to prevent such errors in the future, let us know (e.g., a tutorial?).
flowcietytim
@flowcietytim
Hi @dmitry-timofeev,
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.
Alexander Kolesov
@askolesov
Hi, is there any way to build Merkle proofs for several entries in ProofMapIndex which have a common prefix? Can groups be used for it?
flowcietytim
@flowcietytim
Hey everybody, my team is still developing based on 0.12.1 cause since then we waited for 0.13 and then saw thata 1.0 is coming. With the 1.0RC1 released a month ago, can you already tell how long till 1.0 will be released? We are working on prototypes right now and don't want to waste to much time on the old release, however switching multiple times in short time seems ineffective as well. Any tip would be appreciated :)
Dmitry Timofeev
@dmitry-timofeev

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.

Dmitry Timofeev
@dmitry-timofeev
I would also add that just search over the keys in a single ProofMapIndex and then using 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.
erdeivit
@erdeivit
In the "Exonum: Byzantine fault tolerant protocol for blockchains" paper it is said that "Experiments code will be available at https://github.com/exonum after paper release."D oes someone know where is it?
Alexander Kolesov
@askolesov
@dmitry-timofeev Thanks for the explanation!
flowcietytim
@flowcietytim
@dmitry-timofeev thanks for the answer, that helps a lot.
Alexander Kolesov
@askolesov
Hi! We start proof validation by querying public keys of the validator nodes. But how can we trust this list? If the node is malicious it can fake those keys and the whole transaction log. So how to distinguish fake key list and list resulted with honest configuration updates?
flowcietytim
@flowcietytim

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!

Vyacheslav Gudkov
@vimmerru
Hi, I need to add some domain-specific transactions to genesis block. How it can be achieved?
Alex Ostrovski
@slowli

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).

Dmitry Timofeev
@dmitry-timofeev

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 :-)

flowcietytim
@flowcietytim
Hi @dmitry-timofeev,
the problem occurs without an installed sodium. The file access error occurs on %APPDATA%\Local\Temp\lazysodium\libsodium.dll.
I've uploaded the (hopefully) relevant part of JNI log.
I can confirm, that the error only happens on Windows. Running the same jars in Debian (wsl) works just fine.
Since you're not officialy supporting Windows (as i understand your message) and i have a workaround, this is not high priority though.
Thanks for your support!
Dmitry Timofeev
@dmitry-timofeev

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.

Dmitry Timofeev
@dmitry-timofeev

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.

Vyacheslav Gudkov
@vimmerru
@slowli Thanks for the info. We already solved this by adding necessary data in service constructor
Vyacheslav Gudkov
@vimmerru
Our use case is creation of initial nyms that can onboard others. For crypto currency use case it can be just generation of initial money supply.
Vyacheslav Gudkov
@vimmerru
Hello, i am trying to debug simple service that is very similar to example with state proofs. I have a mutable entity inside of ProofMapIndex. The problem is in about 25% of cases i am getting UnmatchedRootHash on table proof verification. Seems there are some races. Any ideas what can be the reason?
Vyacheslav Gudkov
@vimmerru

getting UnmatchedRootHash on table proof verification

FYI the cause of the problem was usage of entity type with unpredictable ordering and as a result serialization and hashing.

erdeivit
@erdeivit
If I modify any .rs inside the exonum-node folder, how can I compile it in a faster way?
erdeivit
@erdeivit
I mean I can't see the changes when I run the nodes in the cryptocurrency tutorial if I edit anything inside the exonum-node folder
Oleksandr Anyshchenko
@aleksuss
Have you recompiled the node after making changes ?
erdeivit
@erdeivit
That was the point. I was only recompiling exonum-node, not the example.
erdeivit
@erdeivit
I'm not used to work with that high-level code projects but, how do manage about implementing something new? Is there a way to go through the functions? Insert breakpoints? To see the "Local Variables" and that stuff? I normaly click "Start debugging" and I get easy control from the process but here i guess is not that easy. Inside contributing docs there is no reference about that. Maybe it is an low-level doubt.
Alexander Irbis
@alexander-irbis
@erdeivit You can try IntelliJ Idea / CLion with the Rust plugin
Another popular tool is VSCode.
sergiuchuckmisha
@sergiuchuckmisha

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.

Oleksandr Anyshchenko
@aleksuss
Access to the database is now isolated for services. A service cannot get the write access to another service or the blockchain schema. It was introduced in Exonum 0.13.0-rc.2 for security reasons.
Hisham Ismail
@mhishami

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.

Hisham Ismail
@mhishami

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.

Hisham Ismail
@mhishami
Nobody?
flowcietytim
@flowcietytim

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!

2 replies
Oleksandr Anyshchenko
@aleksuss

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

I hope it will help you
Alexander Kolesov
@askolesov
Hello! Is Tendermint's sentry node architecture possible in Exonum? It's the architecture where consensus nodes are hidden for the public and communicates via observers. Thanks.
https://forum.cosmos.network/t/sentry-node-architecture-overview/454
2 replies
flowcietytim
@flowcietytim

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!

6 replies