Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 31 21:24
    dependabot-preview[bot] closed #1835
  • Mar 31 21:24
    dependabot-preview[bot] opened #1843
  • Mar 31 18:04
    alekseysidorov unlabeled #159
  • Mar 31 16:53
    Travis exonum/exonum (v1.0.0) passed (4612)
  • Mar 31 16:29
    Travis exonum/exonum (v1.0.0) passed (4611)
  • Mar 31 16:19
    Travis exonum/exonum (master) passed (4610)
  • Mar 31 15:31

    aleksuss on v1.0.0

    (compare)

  • Mar 31 15:30

    aleksuss on v1.0.0

    (compare)

  • Mar 31 15:29

    aleksuss on v1.0.0

    (compare)

  • Mar 31 15:26
  • Mar 31 15:24

    aleksuss on master

    Release 1.0.0 [ECR-4332] (#1842) (compare)

  • Mar 31 15:24
    aleksuss closed #1842
  • Mar 31 15:24
    codecov[bot] commented #1842
  • Mar 31 14:45
    codecov[bot] commented #1842
  • Mar 31 14:45
    aleksuss synchronize #1842
  • Mar 31 14:23
  • Mar 31 14:16
    codecov[bot] commented #1842
  • Mar 31 14:06
    alekseysidorov review_requested #159
  • Mar 31 14:06
    alekseysidorov labeled #159
  • Mar 31 14:06
    alekseysidorov opened #159
Oleksandr Anyshchenko
@aleksuss
How did you install protobuf ? By brew ?
Dean Harry
@dharry1968
yes, installed by brew :)
Oleksandr Anyshchenko
@aleksuss
Strange. I've never met such issue before. Could you provide full error output ?
Dean Harry
@dharry1968
sure, I will have to do it in the morning, i'm away from my machine now.
Oleksandr Anyshchenko
@aleksuss
Ok. By the way. You can create an issue on github https://github.com/exonum/exonum/issues
Dean Harry
@dharry1968
@aleksuss thanks, I submitted the issue to GitHub :)
Utkarsh Tripathi
@utkarshkvs1
hi @all I'm new here, I was trying to run cryptocurrency-advance tutorial from the docker image given in the repo but it is only running the 8 nodes, the application/service itself is not running
can someone pls look into this?
Oleksandr Anyshchenko
@aleksuss
Utkarsh Tripathi
@utkarshkvs1
yes
@aleksuss
Dean Harry
@dharry1968
trying to get the cryptocurrency advanced demo running under OSX, have tried both Docker and Manual and it is failing when it tries to deploy the service with "No module named exonum_launcher"
Oleksandr Anyshchenko
@aleksuss
@dharry1968 take a look here https://github.com/exonum/exonum-launcher
@utkarshkvs1 create an issue on github please. And don't forget to attach log output.
flowcietytim
@flowcietytim
Hi everybody, i started working with exonum last week and plan to use it in a commercial product. Right now, our team of 2 is developing a poc and managed to get the Crypto Advanced tutorial up and running. We are working with 0.12.1 and i am trying to integrate a simple java app via java light client. However, i always get an error 'Wrong PublicKey size'.
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!
flowcietytim
@flowcietytim
@flowcietytim seems to have been a problem in the conversion from crypto.PublicKey to helpers.PublicKey. Creating the helpers.PublicKey from a ByteString that is created from the crypto.PublicKey.toBytes() instead of .toString() actually works.
Dmitry Timofeev
@dmitry-timofeev
Hi @flowcietytim , great you have figured that out! We will consider adding some conversion methods for crypto primitives to the light client.
flowcietytim
@flowcietytim

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!

Rinat Vasilev
@badadin
Hello. Is there any test server already deployed to connect to it and test my project with Java Light Client inside?
Dmitry Timofeev
@dmitry-timofeev

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.

Sergey Khoroshavin
@skhoroshavin
Hi, is there a light client implementation in Rust? I guess it should be (as server-side crypto is written in Rust anyways, and looks highly modular), but documentation mentions just JS one
Oleksandr Anyshchenko
@aleksuss
@/all DevUpdate: Exonum 1.0-rc.1. Exonum now supports stopping and upgrading service instances (including the possibility of data migrations). https://medium.com/meetbitfury/introducing-exonum-1-0-0-release-candidate-29476428e066
Rinat Vasilev
@badadin
@dmitry-timofeev thank you!
Alex Ostrovski
@slowli
@skhoroshavin There is currently no distinguished light client implementation in Rust, but you're right in that the server-side crypto (and proof verification, which is another major light client component) are both modular, so they would be relatively easy to move to a separate crate. As an ad-hoc solution, it is possible to import proofs from the exonum-merkledb crate and transaction generation from the exonum crate and implement client functionality this way - we've done this in some internal projects.
flowcietytim
@flowcietytim
Hi @dmitry-timofeev thanks for your response! We used a RNG and it's good to know that this won't work. So me moved the ID-Generation to the client-side for now. However, i get an "unexpected wire type" now as transaction error. I guess that has something to do with the way protobuf.js serializes the id compared to rust. Do you have rule of thumb or anything on how you specify numbers in javascript? We've now used uint64 in protobuf and long.js in Javascript, with the afformentioned error. Any tip is appreciated!
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?).
erdeivit
@erdeivit
Good afternoon. I am a student doing a master thesis on different Byzantine consensus protocols in permissioned blockchains. That is why I would like to be able to simulate different numbers of nodes, including Byzantines, and see how long it takes the network to reach a consensus. I've been looking for tutorials, but none of them talk about this. Even the Testing framework excludes any test on the consensus protocol. Is there any way I can do this? Thank you very much and greetings.
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.
erdeivit
@erdeivit
there is any possibility to see nodes log messages in cmd, in the cryptocurrency-advanced tutorial?
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?