-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go quorum interop #1782
Go quorum interop #1782
Conversation
…in privacy) Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
…in privacy) Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
…in privacy) Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Lucas Saldanha <lucascrsaldanha@gmail.com>
Signed-off-by: Lucas Saldanha <lucascrsaldanha@gmail.com>
Signed-off-by: Lucas Saldanha <lucascrsaldanha@gmail.com>
…block'. Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
ethereum/api/src/main/java/org/hyperledger/besu/ethereum/api/jsonrpc/RpcApis.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/hyperledger/besu/ethereum/api/jsonrpc/internal/response/JsonRpcError.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/hyperledger/besu/ethereum/api/jsonrpc/internal/response/JsonRpcError.java
Outdated
Show resolved
Hide resolved
@@ -32,6 +32,8 @@ | |||
private final SubscriptionManager subscriptionManager; | |||
private final Optional<PrivacyQueries> privacyQueries; | |||
|
|||
// TODO-goquorum GoQuorum private txs events |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this TODO staying?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need a GI for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to find out how this is done in GoQuorum and then we can decide what to do with the TODO. We might need a GI for that then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I know what we have to do to support events for the private transactions. I will remove the TODO and add extra information to the ticket that we have.
|
||
@Override | ||
public String getName() { | ||
return RpcMethod.ETH_SEND_RAW_PRIVATE_TRANSACTION.getMethodName(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does eea_sendRaw use same method name as eth_sendRaw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They came up with this new API (eth_sendRawPrivateTransaction)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this one be under the eea package then or would it make sense to move it out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not an eea API ...
ethereum/core/src/main/java/org/hyperledger/besu/ethereum/ProtocolContext.java
Outdated
Show resolved
Hide resolved
...um/core/src/main/java/org/hyperledger/besu/ethereum/core/encoding/TransactionRLPDecoder.java
Outdated
Show resolved
Hide resolved
.isLessThan( | ||
LimitedTransactionsMessages.LIMIT | ||
+ MAX_ADDITIONAL_BYTES)); // TODO: Sally/Mark/Lucas please check that 5 | ||
// is really the max! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait what is this limit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In LimitedTransactionsMessages they use LimitedTransactionsMessages.LIMIT to check how many transactions they can add, but once the limit is reached there are some bytes added with the message.endList(). That means that the size can be bigger than LimitedTransactionsMessages.LIMIT, and I think you can have a maximum of 5 additional bytes ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a test to ensure we handle this scenario nicely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a look at the code again and I think that the 5 additional bytes are right. I've removed the TODO! I don't think we need another test ...
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Should some of those ToDos be resolved?
ethereum/core/src/main/java/org/hyperledger/besu/ethereum/mainnet/ProtocolSpecBuilder.java
Show resolved
Hide resolved
|
||
public class GoQuorumKeyValueStorage implements GoQuorumPrivateStorage { | ||
|
||
// TODO-goquorum We need to think about whether we have to have the atomic commit of public and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this require a decision to be made?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we should probably discuss that once the PR is merged! I'll leave the TODO in to remind us!
|
||
interface Updater { | ||
|
||
// TODO-goquorum Do we need this? I think in quorum they do not have both the public and the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to discuss?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we agreed that we do not need that mapping anymore. Will leave the TODO here and fix that when this PR is merged!
Updater putPrivateStateRootHashMapping( | ||
final Hash publicStateRootHash, final Hash privateStateRootHash); | ||
|
||
// TODO-goquorum Do we need this? I think we are storing the private Tx receipts instead of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to discuss?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we agreed that we do not need that mapping anymore. Will leave the TODO here and fix that when this PR is merged!
@@ -64,6 +65,8 @@ | |||
return Optional.of(TRACE); | |||
} else if (name.equals(PLUGINS.getCliValue())) { | |||
return Optional.of(PLUGINS); | |||
} else if (name.equals(GOQUORUM.getCliValue())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this leaving up to the user to enable the GOQUORUM methods? Do we really need to do this? We should always use the GoQuorum "versions" of the methods if GoQuorum mode is enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be an easy change and we should discuss that. Would prefer to do that after the PR is merged!
-50100, "No privateFor specified in rawTxArgs for GoQuorum raw private transaction."), | ||
GOQUORUM_ONLY_STANDARD_MODE_SUPPORTED( | ||
-50100, | ||
"Mode other than 'standard' mode defined in rawTxArgs for GoQuorum raw private transaction."), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This error msg seems a bit confusing. It could say: "Invalid private transaction mode" or something like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
.isLessThan( | ||
LimitedTransactionsMessages.LIMIT | ||
+ MAX_ADDITIONAL_BYTES)); // TODO: Sally/Mark/Lucas please check that 5 | ||
// is really the max! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a test to ensure we handle this scenario nicely?
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
ethereum/core/src/main/java/org/hyperledger/besu/ethereum/privacy/GoQuorumSendRawTxArgs.java
Outdated
Show resolved
Hide resolved
messageSize -> assertThat(messageSize).isLessThan(LimitedTransactionsMessages.LIMIT)); | ||
messageSize -> | ||
assertThat(messageSize) | ||
.isLessThan(LimitedTransactionsMessages.LIMIT + MAX_ADDITIONAL_BYTES)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we stay under the LIMIT
anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can get over the limit because we are checking the length of the message against LimitedTransactionsMessages.LIMIT before we are adding the length of that RLP encoded list.
Looking at commit messages it looks like this is a self imposed limit. It changes from limiting the number of transactions to limiting the size. I guess that means that it should not matter if there are 5 bytes more. I will slack Abdel to make sure I'm right.
Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Enable Besu to import blocks containing quorum style private transactions * Add RPC to accept quorum style raw private transactions Signed-off-by: Stefan Pingel <stefan.pingel@consensys.net> Signed-off-by: Lucas Saldanha <lucascrsaldanha@gmail.com> Co-authored-by: Lucas Saldanha <lucascrsaldanha@gmail.com>
PR description
Make Besu interop with Quorum privacy