search

hyperledger / besu

An enterprise-grade Java-based, Apache 2.0 licensed Ethereum client https://wiki.hyperledger.org/display/besu
https://www.hyperledger.org/projects/besu
Apache License 2.0
1.52k stars 841 forks source link

Account Permissions onchain doesn't return a error response #1466

Closed ccamaleon5 closed 3 years ago

ccamaleon5 commented 4 years ago

Description

When a raw trasaction(from an account not permitted) is sent to a network with the onchain account permission enabled, no response is received. The clients tested were Web3, openzeppelin-cli and metamask which get stuck waiting for a response.

Steps to Reproduce (Bug)

  1. Deploy Account Permissions smart contract
  2. Set the following flags before start besu service "--permissions-accounts-contract-enabled --permissions-accounts-contract-address=0x0000000000000000000000000000000000008888"
  3. Send a raw transaction using Web3, Openzeppelin-cli or Metamask

Expected behavior: [What you expect to happen] Return an error similar to file account permissions "Error: Sender account not authorized to send transactions"

Actual behavior: [What actually happens] Clients like web3, openzeppelin and metamask are stuck waiting for a response from Besu.

Frequency: [What percentage of the time does it occur?] Always

Versions (Add all that apply)

Additional Information

The behavior when the configuration of account permissions is through files, it returns the following response and works correctly: Error: Sender account not authorized to send transactions

Trace logs using smart contract permissions: 2020-10-16T20:08:17.255+0000 TRACE Account permissioning: Checking transaction 0xdac25aeee2a62ad223404e8e069ff9d58438ba7409a94c03fca8d08663196cd4 2020-10-16T20:08:17.255+0000 TRACE Account permissioning: Permitted transaction 0xdac25aeee2a62ad223404e8e069ff9d58438ba7409a94c03fca8d08663196cd4 from 0x173cf75f0905338597fcd38f5ce13e6840b230e9 2020-10-16T20:08:24.001+0000 TRACE Account permissioning: Checking transaction 0xdac25aeee2a62ad223404e8e069ff9d58438ba7409a94c03fca8d08663196cd4 2020-10-16T20:08:24.002+0000 TRACE Account permissioning - Smart Contract : Checking transaction 0xdac25aeee2a62ad223404e8e069ff9d58438ba7409a94c03fca8d08663196cd4 2020-10-16T20:08:24.079+0000 TRACE Account permissioning - Smart Contract: Rejected transaction 0xdac25aeee2a62ad223404e8e069ff9d58438ba7409a94c03fca8d08663196cd4 from 0x173cf75f0905338597fcd38f5ce13e6840b230e9 2020-10-16T20:08:24.079+0000 TRACE Account permissioning: Rejected transaction 0xdac25aeee2a62ad223404e8e069ff9d58438ba7409a94c03fca8d08663196cd4 from 0x173cf75f0905338597fcd38f5ce13e6840b230e9

Trace logs using file account permission: 2020-10-16T19:26:04.943+0000 TRACE Account permissioning: Checking transaction 0xdd614b4c11fa058de025bbf49361b4a589d5a1cb22c46229d482896faf2275a9 2020-10-16T19:26:04.943+0000 TRACE Account permissioning - Local Config: Checking transaction 0xdd614b4c11fa058de025bbf49361b4a589d5a1cb22c46229d482896faf2275a9 2020-10-16T19:26:04.944+0000 TRACE Account permissioning - Local Config: Rejected transaction 0xdd614b4c11fa058de025bbf49361b4a589d5a1cb22c46229d482896faf2275a9 from 0x173cf75f0905338597fcd38f5ce13e6840b230e9 2020-10-16T19:26:04.944+0000 TRACE Account permissioning: Rejected transaction 0xdd614b4c11fa058de025bbf49361b4a589d5a1cb22c46229d482896faf2275a9 from 0x173cf75f0905338597fcd38f5ce13e6840b230e9

MadelineMurray commented 4 years ago

hi @ccamaleon5 - this is expected behaviour. For local permissioning, the validation is performed at the JSON-RPC level but not for onchain permissioning. This is illustrated here: https://besu.hyperledger.org/en/stable/Concepts/Permissioning/Permissioning-Overview/#onchain

ccamaleon5 commented 4 years ago

I know that the onchain permissioning is based on smart contracts and that some change of the rules needs a consensus and it is not immediate. The problem occurs when a transaction is sent. It is assumed that when sending the transaction, it is evaluated against the smart contract, if the account that sends the transaction is allowed, then the smart contrat will return true or false. When this response from smart contract reaches Besu, it does not return any response to the client(web3, openzeppelin or metamask). I think it should return the same response that the permissioned file returns which is "Error: Sender account not authorized to send transactions". The client is stuck waiting for the answer from Besu, but it never arrives.

lucassaldanha commented 4 years ago

Thanks for the feedback @ccamaleon5!

The reason the tx isn't immediately discarded is due to the fact that, depending on the order of blocks and txs being processed, that transaction might be valid. Imagine you have two transactions, Tx1 is whitelisting account A1 and Tx2 is from account A1 to deploy a contract.

If in a node in the network Tx2 is processed by a node before Tx1 and immediately discarded, and on another node Tx1 is processed first (and subsequently Tx2), the outcome for the user is even worse, as it might look like the tx succeeded (from node 2 point of view), but if the chain followed by node 1 is the canonical chain, it hasn't succeeded.

So, at a specific moment in time, the tx might be valid or invalid, depending on the view of the network that the node has (of course eventually they'll converge into a single canonical truth, but it can take a few blocks). This is in part due to the asynchronous nature of how tx are propagated and blocks added to a chain.

We believe our approach is better because the client can always call the permissioning contract before sending the tx to check if the sender is allowed.

However, I do understand that in some private networks, the tx propagation delay isn't that high, and rejecting the tx straight away might be useful. I'll discuss with the team if we should implement a config option to change this behaviour, so users can opt-in to this "ahead of time enforcement", but atm the default behaviour won't change. If the pending tx is an issue for your use case, you can add a call to the permissioning contract before submitting the tx and only proceed if they response is true.

MadelineMurray commented 4 years ago

@lucassaldanha - we're different from GoQuorum here aren't we? ie, GoQuorum would reject the txn in this case?

elranu commented 3 years ago

@lucassaldanha If I send a transaction to a node of an Account (a1) which isn´t permitted yet. Later I permissioned it. When I try to send a new transaction to the same node with a1. The transaction is stuck with no error. If I reset the node, and try again to send the transaction the transaction works successfully.

Is there any way to unstuck a1 without resetting the node?

Regards, Mariano

lucassaldanha commented 3 years ago

@elranu by "transaction stuck" do you mean it has been accepted in the tx pool but hasn't been included in a block?

onigiri-x commented 3 years ago

Experiencing this issue as well. Metamask calls the error. Using Clique blockchain

Able to see balance in metamask (many thousand eth)

Able to connect to network in metamask

Try to make transaction (send 1 eth), fails with "Sender account not authorized to send transactions" rpc error

Is there any other case this error would trigger? I have confirmed that my account sending eth is on the accounts whitelist

lucassaldanha commented 3 years ago

@victorwiebe if you could share the config that you are using in you besu nodes and the steps to reproduce this issue it would help us a lot!

ItayPodhajcer commented 3 years ago

Having the same issue.

Using a four nodes IBFT deployment with on-chain permissioning turned on and configured.

When using an allowed account to perform a transaction it works well, but if an account that was not whitelisted in the network is used, the call to the node hangs.

The only way to release the call is by resetting the node.

I would expect an error to be returned from the node in case of non-whitelisted accounts.

vmichalik commented 3 years ago

Hi all, we're looking at this issue this week and might have some follow up questions for you in the thread, thanks for your patience!