adridadou / eth-propeller-core Goto Github PK

In order to avoid hadnling same event on multiple clients it would be great to add some extra information about the event, line txHash where that event happened.

Right now, you need to return a CompletableFuture
The idea is to return a SmartContractCall that has two getters

• GetResult - get the result as soon as the transaction has been added to a block
• GetResultSafe(x) - get the result as soon as the transaction has been added to a block that has been confirmed x times

This way, you can decide whether you want to answer as soon as the result is back or you want a more safe but slow function that will return the value only if it has been confirmed enough time and will throw if an reorg has happened

I would be nice to have a possibility to handle contract calls failures, for CompletableFutures.
Currently the exception propagation stops at 'EthereumProxy.processTransactions()'

thank you @ESchouten for your PR. Your change on how to handle reading the blocks made me think of another improvement that we should do.

Right now, the only thing we do is keeping track of the latest block number we've read and load / play the difference between the latest played and the latest available.

But here is the issue, in case of a re-org, we won't be playing new blocks that we've never seen.

So here is a proposal to handle that.

Instead of keeping the latest block number, we keep the 1000 latest block hash (this number should be configurable)

Now every time we check if there are new blocks, we do the following:

• what's the latest block hash?
• if the latest block is in the list, do nothing
  done
• if not, load the latest block
• while parent hash is not in the list, load the parent block
• play all the loaded blocks
• add them to the list

How to maintain the list? Because the order there is not important, it's just a way of saying what we've already seen or not, keeping it in no particular order but limit the size should be enough.

Having this list big enough should prevent any issues if we have more than 2 competing chains.
Also, because we only keep the hashes, it doesn't take too much memory so keeping 1000 or even more shouldn't be an issue.

I'd love to get someone's feedback before implementing that. Maybe some improvement ideas

different languages define void differently.
Java is void
Scala is Unit

it should be possible to define Void for each language (just like future)

Hi,

I noticed Bintray is discontinued.

"Thanks for supporting Bintray! This service has now been sunset, and to assist with migration to the JFrog Platform, paid accounts can login until July 4th."

I have some difficulty building the project because of the rocksdbjni and solcJ-all dependency can't be found from the ethereumj-core dependency. Is this maybe related?

It would be very helpful for any backend implementation to have a set of tests to check if their implementation works or not

We have different issues with the way futures, async etc is being handled in eth-propeller

The idea would be to do the following:

• having a queue of transactions that need to be handled
• a consumer that takes those transactions and send them to the network
• an observer that will listen to new blocks and will check whether the transaction has been added for each of them

This means removing the while(true) completely and use Observable (we should upgrade to RxJava 2.0)

Also to take into account, the transaction consumer needs to be single threaded, or at least single threaded for a particular private key, so it can effectively do nonce calculation and never create a bad nonce

When the client has been offline, replaying all blocks mined since is necessary to handle events emitted in smart contracts the application is subscribed to.

There are some discrepancies with the compilation output of Truffle:

• CompilationResult class expects the output to be a map of contracts, that is not true for Truffle (output is a single contract). Easy to fix adding method parse() to SolidityContractDetails
• abi field is an array rather than a String
• ... might be more, couldn't go further

Latest Solidity compiler adds new field 'signature' to the API specification.
Currently this leads to the "error while deserialising ABI" exception when trying to work with the contracts.

Right now it is not possible to listen to anonymous events.

Doesn't stop the block processing anymore but still something to have a look at:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at org.adridadou.ethereum.rpc.EthereumRpc.toEventInfo(EthereumRpc.java:169)
at org.adridadou.ethereum.rpc.EthereumRpc.lambda$toEventInfos$7(EthereumRpc.java:164)
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at org.adridadou.ethereum.rpc.EthereumRpc.toEventInfos(EthereumRpc.java:164)
at org.adridadou.ethereum.rpc.EthereumRpc.toReceipt(EthereumRpc.java:160)
at org.adridadou.ethereum.rpc.EthereumRpc.lambda$toBlockInfo$6(EthereumRpc.java:143)

Librairies are not handled yet