ketola / jlibra Goto Github PK

I'm submitting a transaction using admission control grpc, but the transaction submission does not generate any events. I'm checking against libra cli and librabrowser.io and nothing appears. ac_status is Accepted, mempool status is Valid and no error appears. I'm also trying your TransferExample but still no event appears. Is there something that I'm missing?

Currently, there are several different ways of creating value objects and setting values to them (public constructors, builder methods, values in constructor, getters/setters etc). Propose a project-wide pattern for the value objects and fix the current implementation to follow this pattern.

An exception occurs when trying to run the example. Any ideas why and how to solve this?

Exception in thread "main" java.lang.NullPointerException
	at dev.jlibra.example.TransferExample.main(TransferExample.java:66)

Currently, many of the examples require Thread.sleep to be used to wait for minting and transactions to be executed. The correct way would be to check the transaction state from the api and proceed when it has been executed.

Implement a poller that can be used to check if

• a transaction has been executed
• minting has been finished

The poller could wait some time between the polls if necessary and end the polling after a timeout period has passed.

At first this could be implemented in the examples module and later if it looks like something useful it could be extracted to the core or some other module.

Currently, the Query class has methods:

• getAccountStateQueries
• getAccountTransactionBySequenceNumberQueries
• getTransactionsQueries

The corresponding methods in the UpdateToLatestLedgerResult class are

• getAccountResources
• getAccountTransactionsBySequenceNumber
• getTransactions

It might not be obvious what method contains the result of the queries. To fix this, rename the UpdateToLatestLedgerResult class methods to

• getAccountStateQueryResults
• getAccountTransactionBySequenceNumberQueryResults
• getTransactionsQueryResults

I test it on android device, when send Libra, sometime fail with the follow error:

2019-11-13 16:09:36.052 2487-4755/test.app W/System.err: io.grpc.StatusRuntimeException: UNAVAILABLE: HTTP/2 error code: NO_ERROR
2019-11-13 16:09:36.053 2487-4755/test.app W/System.err: Received Goaway
2019-11-13 16:09:36.053 2487-4755/test.app W/System.err: at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:230)
2019-11-13 16:09:36.053 2487-4755/test.app W/System.err: at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:211)
2019-11-13 16:09:36.053 2487-4755/test.app W/System.err: at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:144)
2019-11-13 16:09:36.054 2487-4755/test.app W/System.err: at admission_control.AdmissionControlGrpc$AdmissionControlBlockingStub.submitTransaction(AdmissionControlGrpc.java:211)
2019-11-13 16:09:36.054 2487-4755/test.app W/System.err: at dev.jlibra.admissioncontrol.AdmissionControl.submitTransaction(AdmissionControl.java:34)

thanks for your reply.

This commit will introduce a breaking change in the account state.
diem/diem@b48bf25

The value needs to be deserialized similarly as it's done for 'delegated_withdrawal_capability' currently.

• The test should be in a separate integration-tests module
• Libra supports multisig accounts with max 32 keys and it is possible to define how many signatures are required for a transaction. To test this, create a multisig account with 32 keys, set the threshold to something smaller like 30, create a p2p transaction and verify that the transaction was successful.
• The test should be run as a part of the build

The old integration tests were deleted when switching to json-rpc api, but they can be used as a reference: https://github.com/ketola/jlibra/tree/testnet-20200325/jlibra-integration-tests

Information about different options can be found here: https://github.com/grpc/grpc-java/blob/master/SECURITY.md

Check if the library is usable for android development. If not, investigate if support can be added.

After the last Testnet update (https://community.libra.org/t/testnet-update-july-24th/1362) jlibra cannot commit transactions against Testnet, but also not against a currently build (master or testnet branch) local Rust Node.
Most likely this is due to peer_to_peer_transaction.bin being too old as there is a unknown_script error in the response after transaction submit.

Hello, first of all, thanks for your work !

I'm using 0.1.1 snapshot and when doing this :

UpdateToLatestLedgerResult result = admissionControl.updateToLatestLedger(ImmutableQuery.builder()
				.addAccountTransactionBySequenceNumberQueries(
						ImmutableGetAccountTransactionBySequenceNumber.builder()
								.accountAddress(Hex.decode(address))
								.sequenceNumber(sequenceNumber)
								.build())
				.build());
System.out.println(result.getAccountTransactionsBySequenceNumber().size());

I always have 1 result even if the sequence for the address doesn't exists : SignedTransactionWithProof{senderPublicKey=[], senderSignature=[], events=[]}

Is it normal ? From my point of view, i should have no results at all no ?

Since on or two days, my code that creates transaction using your library wasn't working anymore... I thought i was crazy because all worked fine but now i have a "submit txn rejected" error everytime.

So i get your sources again and after doing mvn verify, i get :

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running dev.jlibra.SimpleTransactionIT
08:16:07.614| Balance for 0703a61585597d9b56a46a658464738dff58222b4393d32dd9899bedb58666e9 is 1000000000
08:16:07.622| Generated seed: vital unable dish comic grocery blush invest gun two wolf stand range zoo domain milk renew soup photo
Transaction submitted with result: SubmitTransactionResult{admissionControlStatus=code: Rejected
message: "submit txn rejected"
, mempoolStatus=, vmStatus=, statusCase=AC_STATUS}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.401 s <<< FAILURE! - in dev.jlibra.SimpleTransactionIT
[ERROR] transferTest(dev.jlibra.SimpleTransactionIT)  Time elapsed: 17.054 s  <<< FAILURE!
java.lang.AssertionError: expected:<Accepted> but was:<Rejected>
	at dev.jlibra.SimpleTransactionIT.transfer(SimpleTransactionIT.java:164)
	at dev.jlibra.SimpleTransactionIT.transferTest(SimpleTransactionIT.java:107)

[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   SimpleTransactionIT.transferTest:107->transfer:164 expected:<Accepted> but was:<Rejected

Seems something change with libra

It would be immutable and could have methods for converting it to hex string.
It would be used in the value objects instead of raw byte arrays.

The AdmissionControlGrpc class supports async requests through
AdmissionControlFutureStub stub = AdmissionControlGrpc.newFutureStub(channel);

• implement support for async requests by new methods to AdmissionControl class
• implement an example

How did you manage to perform key rotation?
I tried submitting a transaction doing key rotation, but I got stuck.
I tried creating a new keypair with private key K_s and public key K_v. I’m creating a raw transaction where the program contains the code for rotate_authentication_key and as argument the sha3(K_v) with argument type byte array. I’m also setting the sender's account. Then, I’m creating a signed transaction with raw transaction bytes, sender public key(K_v) and sender signature (raw transaction signed with K_s) and submit it to admission control. The issue is I’m getting an InvalidAuthKey error. Is there something I’m missing or that I’m doing wrong?

The libra repository has a pre-made script for doing a key rotation: https://github.com/libra/libra/blob/master/language/stdlib/transaction_scripts/rotate_authentication_key.mvir

The idea is that you should be able to change the keys for your address while keeping the address the same.

• You will need to compile the script and use it like the peer_to_peer transfer is used currently
• Create an example class where the rotation is performed

Hello! Can you please provide some insight about how you obtained your transfer.bin file?

According to last update on libra testnet
Testnet push announcement for 07/23

The Json-RPC API is changed from get_account_state to get_account

Additionally, they added /v1 for JSONRPC endpoint, but they will redirect to latest API version if not present.

SubmitTransactionResult result = admissionControl.submitTransaction(publicKey, privateKey,transaction);

gives ==>
Admission control status: Accepted
Mempool status: Valid
VM status: validation {
code: UnknownScript
message: "none"
}

Tried by increasing maxGasAmount but still getting same error

Passing metadata in a transaction has been added to libra: diem/diem@cdab938

Create an example of this:

• Compile the new move script and add it to jlibra
• Create an example in the examples module

• Create a parent pom.xml in the root of the project (could be named jlibra-parent)
• Create 3 submodules: jlibra, examples ja integration-tests
• Move the current core code to the jlibra module
• Move the examples under the examples module

(the integration tests module can be left empty now, implementing the integration tests are a separate task)

When using your example GetAccountStateExample with an address with lots of libras : da2f86f7ee9b10317fd1d1ad31f5059efceb97589042be20a817be26d5be06b3.

The accountResource.getBalanceInMicroLibras() returns 1073435 but if you check in libra explorer, the value is 19,001.073435

• The test should be in a separate integration-tests module
• The test should create a new key pair, rotate the authentication key and verify that the key was rotated (the KeyRotationExample contains the steps to do this)

The old integration tests were deleted when switching to json-rpc api, but they can be used as a reference: https://github.com/ketola/jlibra/tree/testnet-20200325/jlibra-integration-tests

I think this is everyone sees coming. We need to introduce a logging framework. In some places it is necessary to log warnings or errors

• The latest testnet version has changed the address size from 32 bytes to 16 bytes. Implement support for this change.

https://community.libra.org/t/testnet-push-announcement-for-3-25/2663

updateToLatestLedger supports GetEventsByEventAccessPath

• Implement support for it
• Create an example

Note that there are branches with wip for other examples. Those probably have features that can be utilized on this one, so check them before starting to implement (or ask)

Error can be reproduced by adding this test to AccountResourceTest.java:

    @Test
    public void outOfMemoryError() {
        ByteSequence blob = ByteSequence
                .from("01000000200000008f5fbb9486acc5fb90f1a6be43a0013d4a7f7f06e3d5fe995be1e9b272c09b5dc0c62d00000000000000030000000000000020000000e7753442710f04596279f6ea097c48782b0683e8b50071e8f2e34be523d7f2c5000000000000000020000000885ae34cf1f18d0c970b416afc7c5475f132511c5f3bbdce4af52ea09a0fd7030000000000000000");

        AccountStateWithProof accountStateWithProof = AccountStateWithProof.newBuilder()
                .setBlob(AccountStateBlob.newBuilder().setBlob(blob.toByteString()))
                .build();
        assertThat(AccountResource.fromGrpcObject(accountStateWithProof).size(), is(1));
    }

It should somehow sanity check keyLength and valLength values before using them to allocate memory for too big byte[]. E.g. rule of thumb may be "can't be greater than remaining bytes in the message".

It would be nice to have custom exception class to use instead of generic RuntimeException. It is useful by developers to handle exceptions coming directly from JLibra.

Due to problems in IDEs and for clarity and SoC, the gRPC stub generation step should be moved to an own module.

The testnet has been updated with breaking changes. Please, do the needful. 😉

Currently, the error response cannot be properly handled because of a bug in the simple-json-rpc library.
I have created an issue and a pull-request to fix the bug: arteam/simple-json-rpc#39

After the issue is fixed the new implementation has to be taken in to use and throw an exception that contains information about the error.

We should have integration tests to know if there have been breaking changes in the libra api or errors in our code that have been missed by unit tests.

For this:

• create a new jlibra-integration-tests module
• the tests of this module should not be run during the normal build (mvn install, mvn verify), instead, the tests should require defining another goal or maven profile
• The first test could create two key pairs, mint libras for one of the accounts, transfer it to the other and verify the transaction.

please
Please add an example of:
Get the committed transactions by version range.
this in libra client :(query txn_range)

Hello,

Looks like the last release way on May 12th. Can you please do a new maven release with latest changes?

The faucet api is being changed to support only POST requests (diem/diem@69979da)

• Change the mint example to use POST (+ elsewhere where minting is used)
• Now when the examples are in a separate module, it's ok to add a library for making the request instead of using java core http features only.

Investigate is there any benefits of the pooling the grpc api connections. Are there any ready-made libraries for this?

can't find
ImmutableGetAccountState
ImmutableQuery
ImmutableProgram
ImmutableTransaction
in dev.jlibra.admissioncontrol.query.

The provided example: https://github.com/ketola/jlibra/blob/master/jlibra-examples/src/main/java/dev/jlibra/example/GetTransactionsExample.java is broken.
The returning error is: Only Script payload is supported (i.e. from Transaction class)

btw, nice project ;)

Libra has changed it's serialization to https://github.com/libra/libra/tree/master/common/canonical_serialization

Until it is implemented in JLibra, the transactions will fail.

• The test should be in a separate integration-tests module
• The test should create two new key pairs, mint money to the first account, transfer some money to the second and verify that the money was transferred
• The test should be run as a part of the build

The old integration tests were deleted when switching to json-rpc api, but they can be used as a reference: https://github.com/ketola/jlibra/tree/testnet-20200325/jlibra-integration-tests

• Use the grpc api to fetch transactions for an account. If possible list transactions, the amount of libra sent and the to / from addresses (same idea as with the block explorers https://www.libravista.com/address/7e92395c356879d8613a27e10cfce13f448db3cade1bc5f908402e8dc008346f)

• Printing the info to the system.out is enough (like in the other examples)

Based on the libra documentation and source code comments the only ok response is a "Valid" code in AdmissionControlStatus. All other cases (VMStatus with all codes and MempoolStatus with all codes) are errors.

• Create a result class for the successful response
• Create exceptions (AdmissionControlException, MempoolException, VirtualMachineException) with status codes, messages and possible status code explanations for error cases. All exception should extend a common exception like LibraTransactionException

I retrieved the master branch (after your merged branch 'transaction-serialization') and when running mvn verify, the tests fails (my project test is also failing).

[INFO] Running dev.jlibra.SimpleTransactionIT
16:30:59.585| Balance for 0703a61585597d9b56a46a658464738dff58222b4393d32dd9899bedb58666e9 is 2999923995
16:30:59.593| Generated seed: major hole canal noise emerge meat enable neglect alcohol town govern skate soft excuse cereal room differ mouse
Transaction submitted with result: SubmitTransactionResult{admissionControlStatus=, mempoolStatus=, vmStatus=major_status: 3
, statusCase=VM_STATUS}
16:30:59.980| Balance for 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60 is 0
16:31:01.087| Balance for 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60 is 0
16:31:02.188| Balance for 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60 is 0
16:31:04.293| Balance for 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60 is 0
16:31:07.396| Balance for 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60 is 0
16:31:12.499| Balance for 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60 is 0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 22.556 s <<< FAILURE! - in dev.jlibra.SimpleTransactionIT
[ERROR] transferTest(dev.jlibra.SimpleTransactionIT)  Time elapsed: 22.25 s  <<< ERROR!
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in dev.jlibra.SimpleTransactionIT Account address: 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60, expected balance: 1000, actual balance: 0 expected:<0> but was:<1000> within 20 seconds.
	at dev.jlibra.SimpleTransactionIT.transferTest(SimpleTransactionIT.java:114)
Caused by: java.lang.AssertionError: Account address: 37b7de33f04fefc1c038c5f520dc83a35af848b1bbe8cc04a9826e4f9ce15a60, expected balance: 1000, actual balance: 0 expected:<0> but was:<1000>
	at dev.jlibra.SimpleTransactionIT.lambda$transferTest$0(SimpleTransactionIT.java:118)

Currently, a channel is opened and shutdown for every request sent to the libra grpc api. Plan and implement a solution to do this effectively so that the channel could preferably be reused in other requests as well.

It's possible to create a single-currency account with the faucet api but it's not possible to directly add another currency to the account.
I guess that it's possible to add another currency with the add_currency_to_account script : https://github.com/libra/libra/blob/master/language/stdlib/transaction_scripts/add_currency_to_account.move

Try this and create an example of it.