Skip to content
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

Queue malice reports and fix the unit tests. #129

Merged
merged 16 commits into from
May 30, 2019
Merged

Queue malice reports and fix the unit tests. #129

merged 16 commits into from
May 30, 2019

Conversation

afck
Copy link
Collaborator

@afck afck commented Apr 23, 2019

This adds the malice report queue: Reports are included whenever we create a block ourselves, and they are also being resent as regular transactions until they have been successfully included in a block.

reportMalicious now matches the ABI used by the validator set code. It also checks whether the removed validator exists.

Closes #107.
Closes #93.

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

This still doesn't fix a single test (#93), since there are several remaining problems:

  • We'd need to either add a permissions contract or an option to not call reportMalicious with 0 gas.
  • Even if I call it with gas, it fails for some reason: after reportMalicious, the validator set is still the same.

@varasev
Copy link

varasev commented Apr 23, 2019

Could you please clarify where we could see the unit test code for this test contract?

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

Sure, this is about engines::validator_set::contract::tests::reports_validators. But it still fails here.

@phahulin
Copy link

Could you also tell how the bytecode inconstructor was generated?

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

I generated the bytcode using Remix from ethcore/res/validator_contract.sol.

@phahulin
Copy link

I tried too, but got a different one 😆
Did you use compiler version:0.5.0+commit.1d4f565a without optimization?

@varasev
Copy link

varasev commented Apr 23, 2019

Even if I call it with gas, it fails for some reason: after reportMalicious, the validator set is still the same.

How do you determine the fact that the validator set is still the same? Seems there are no such checks in

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

Weird; I used the default: 0.5.1+commit.c8a2cb62 without optimization.

How do you determine the fact that the validator set is still the same?

I added print statements right after where getValidators was called.

@vkomenda
Copy link

@afck, is emitInitiateChange called? If not then the validator set is not changed in Parity.

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

It is being called, multiple times, in blocks 2 and 3.

@vkomenda
Copy link

Can you check whether this line is called?

validator_set::events::initiate_change::parse_log((log.topics.clone(), log.data.clone()).into()).ok()

This is where the new set of validators should be coming from.

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

Looks like that never gets called, no.

@vkomenda
Copy link

I recall that it can only be called on the start of an epoch.

@phahulin
Copy link

Weird; I used the default: 0.5.1+commit.c8a2cb62 without optimization.

I still get a bit different bytecode

60806040526040805190810160405280737d577a597b2742b498cb5cf0c26cdcd726d39e6e73ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020017382a978b3f5962a5b0957d9ee9eef472ee55b42f173ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681525060009060026100a9929190610159565b503480156100b657600080fd5b5060008090505b60008054905081101561015357806001600080848154811015156100dd57fe5b9060005260206000200160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000208190555080806001019150506100bd565b50610226565b8280548282559060005260206000209081019282156101d2579160200282015b828111156101d15782518260006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555091602001919060010190610179565b5b5090506101df91906101e3565b5090565b61022391905b8082111561021f57600081816101000a81549073ffffffffffffffffffffffffffffffffffffffff0219169055506001016101e9565b5090565b90565b6107c3806102356000396000f3fe608060405260043610610088576000357c01000000000000000000000000000000000000000000000000000000009004806335aa2e441461008d5780633d3b545814610108578063752862111461013757806393b4e25e1461014e578063b7ab4db514610165578063c476dd40146101d1578063d8f2e0bf14610281578063fd6e1b50146102d8575b600080fd5b34801561009957600080fd5b506100c6600480360360208110156100b057600080fd5b8101908080359060200190929190505050610329565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561011457600080fd5b5061011d610367565b604051808215151515815260200191505060405180910390f35b34801561014357600080fd5b5061014c610371565b005b34801561015a57600080fd5b50610163610373565b005b34801561017157600080fd5b5061017a610426565b6040518080602001828103825283818151815260200191508051906020019060200280838360005b838110156101bd5780820151818401526020810190506101a2565b505050509050019250505060405180910390f35b3480156101dd57600080fd5b5061027f600480360360608110156101f457600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291908035906020019064010000000081111561023b57600080fd5b82018360208201111561024d57600080fd5b8035906020019184600183028401116401000000008311171561026f57600080fd5b90919293919293905050506104b4565b005b34801561028d57600080fd5b506102966106dc565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b3480156102e457600080fd5b50610327600480360360208110156102fb57600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050610702565b005b60008181548110151561033857fe5b906000526020600020016000915054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b6000804311905090565b565b60014303407f55252fa6eee4741b4e24a74a70e9c11fd2c2281df8d6ea13126ff845f7825c8960006040518080602001828103825283818154815260200191508054801561041657602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190600101908083116103cc575b50509250505060405180910390a2565b606060008054806020026020016040519081016040528092919081815260200182805480156104aa57602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019060010190808311610460575b5050505050905090565b8373ffffffffffffffffffffffffffffffffffffffff166000600160008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205481548110151561051957fe5b9060005260206000200160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1614156106d657600060016000805490500381548110151561057757fe5b9060005260206000200160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff166000600160008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548154811015156105f057fe5b9060005260206000200160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550600160008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060009055600060016000805490500381548110151561069257fe5b9060005260206000200160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560008054809190600190036106d49190610746565b505b50505050565b600260009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b80600260006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b81548183558181111561076d5781836000526020600020918201910161076c9190610772565b5b505050565b61079491905b80821115610790576000816000905550600101610778565b5090565b9056fea165627a7a7230582011b1b040c9e77dc165ca7a41163a48c2bd4b08464c831cb958581d9c2383f13b0029

the last 34 bytes are different. Here are my remix settings:
pr-129-bytecode
Sorry if I'm missing something 🙏

@varasev
Copy link

varasev commented Apr 23, 2019

For the test contract https://github.com/poanetwork/parity-ethereum/blob/d9c611f11beb7fc777f2da56cbc8fab60fcd381b/ethcore/res/validator_contract.sol it doesn't matter whether the emitInitiateChange is called or not, because the validators array is changed directly by the reportMalicious in this test contract. So, if the getValidators() getter still returns the same validator set (consisting of two validators), it means that the reportMalicious wasn't called.

@vkomenda
Copy link

@varasev, reportMalicious only changes the validator set in the contract. To get to Parity, it should also be received by Parity as part of InitiateChange, which doesn't happen.

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

it means that the reportMalicious wasn't called.

…or that the call failed. Which is plausible because it's tried with zero gas. But even with default gas it failed for me, and that's what I'm having trouble debugging.

reportMalicious only changes the validator set in the contract

I'm not sure about that. Parity calls getValidators in several places, and that method should definitely return the new validator set if reportMalicious succeeded. But it looks like it doesn't.

@afck
Copy link
Collaborator Author

afck commented Apr 23, 2019

the last 34 bytes are different.

If I try again I'm getting yet another bytecode:

60806040526040805190810160405280737d577a597b2742b498cb5cf0c26cdcd726d39e6e73ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020017382a978b3f5962a5b0957d9ee9eef472ee55b42f173ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681525060009060026100a9929190610159565b503480156100b657600080fd5b5060008090505b60008054905081101561015357806001600080848154811015156100dd57fe5b9060005260206000200160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000208190555080806001019150506100bd565b50610226565b8280548282559060005260206000209081019282156101d2579160200282015b828111156101d15782518260006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555091602001919060010190610179565b5b5090506101df91906101e3565b5090565b61022391905b8082111561021f57600081816101000a81549073ffffffffffffffffffffffffffffffffffffffff0219169055506001016101e9565b5090565b90565b6107c3806102356000396000f3fe608060405260043610610088576000357c01000000000000000000000000000000000000000000000000000000009004806335aa2e441461008d5780633d3b545814610108578063752862111461013757806393b4e25e1461014e578063b7ab4db514610165578063c476dd40146101d1578063d8f2e0bf14610281578063fd6e1b50146102d8575b600080fd5b34801561009957600080fd5b506100c6600480360360208110156100b057600080fd5b8101908080359060200190929190505050610329565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561011457600080fd5b5061011d610367565b604051808215151515815260200191505060405180910390f35b34801561014357600080fd5b5061014c610371565b005b34801561015a57600080fd5b50610163610373565b005b34801561017157600080fd5b5061017a610426565b6040518080602001828103825283818151815260200191508051906020019060200280838360005b838110156101bd5780820151818401526020810190506101a2565b505050509050019250505060405180910390f35b3480156101dd57600080fd5b5061027f600480360360608110156101f457600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291908035906020019064010000000081111561023b57600080fd5b82018360208201111561024d57600080fd5b8035906020019184600183028401116401000000008311171561026f57600080fd5b90919293919293905050506104b4565b005b34801561028d57600080fd5b506102966106dc565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b3480156102e457600080fd5b50610327600480360360208110156102fb57600080fd5b81019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050610702565b005b60008181548110151561033857fe5b906000526020600020016000915054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b6000804311905090565b565b60014303407f55252fa6eee4741b4e24a74a70e9c11fd2c2281df8d6ea13126ff845f7825c8960006040518080602001828103825283818154815260200191508054801561041657602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190600101908083116103cc575b50509250505060405180910390a2565b606060008054806020026020016040519081016040528092919081815260200182805480156104aa57602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019060010190808311610460575b5050505050905090565b8373ffffffffffffffffffffffffffffffffffffffff166000600160008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205481548110151561051957fe5b9060005260206000200160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1614156106d657600060016000805490500381548110151561057757fe5b9060005260206000200160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff166000600160008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548154811015156105f057fe5b9060005260206000200160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550600160008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060009055600060016000805490500381548110151561069257fe5b9060005260206000200160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560008054809190600190036106d49190610746565b505b50505050565b600260009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b80600260006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b81548183558181111561076d5781836000526020600020918201910161076c9190610772565b5b505050565b61079491905b80821115610790576000816000905550600101610778565b5090565b9056fea165627a7a7230582077dd76bdfd89664cbf97a7ddc4b38b04951cdfa914c1521b9a1bc0c6e1186c0b0029

No idea what's going on. Is Remix putting some kind of session identifier into the bytecode??

@varasev
Copy link

varasev commented Apr 23, 2019

@varasev, reportMalicious only changes the validator set in the contract. To get to Parity, it should also be received by Parity as part of InitiateChange, which doesn't happen.

Sure, I'm just saying that the reportMalicious is not called by this unit test.

@vkomenda
Copy link

Sure, I'm just saying that the reportMalicious is not called by this unit test.

But it does.

@phahulin
Copy link

phahulin commented Apr 23, 2019

Is Remix putting some kind of session identifier into the bytecode??

I just added some empty lines, comments, removed some existing comments, recompiled and those last 34 bytes changed. Probably it adds some hash of the source code into the bytecode 🤷‍♂️ I'll create an issue to their repo to ask about it (here it is)

@varasev
Copy link

varasev commented Apr 23, 2019

If the reportMalicious was called successfully, the getValidators would return only one item instead of two. @afck says that it returns two items.

@vkomenda
Copy link

I added a print after the call to reportMalicious and it did get called OK.

@varasev
Copy link

varasev commented Apr 23, 2019

I added a print after the call to reportMalicious and it did get called OK.

Could you show you test code for that?

@vkomenda
Copy link

diff --git a/ethcore/src/engines/validator_set/contract.rs b/ethcore/src/engines/validator_set/contract.rs
index 9defe203f..3619bd15d 100644
--- a/ethcore/src/engines/validator_set/contract.rs
+++ b/ethcore/src/engines/validator_set/contract.rs
@@ -120,8 +120,8 @@ impl ValidatorSet for ValidatorContract {
        fn report_malicious(&self, address: &Address, _set_block: BlockNumber, block: BlockNumber, proof: Bytes) {
                let data = validator_report::functions::report_malicious::encode_input(*address, block, proof);
                match self.transact(data) {
-                       Ok(_) => warn!(target: "engine", "Reported malicious validator {}", address),
-                       Err(s) => warn!(target: "engine", "Validator {} could not be reported {}", address, s),
+                       Ok(_) => println!("Reported malicious validator {}", address),
+                       Err(s) => println!("Validator {} could not be reported {}", address, s),
                }
        }
 
---- engines::validator_set::contract::tests::reports_validators stdout ----
Reported malicious validator 0x7d57…9e6e
thread 'engines::validator_set::contract::tests::reports_validators' panicked at 'assertion failed: `(left == right)`
  left: `3`,
 right: `2`', ethcore/src/engines/validator_set/contract.rs:229:3

@vkomenda
Copy link

Parity calls getValidators in several places, and that method should definitely return the new validator set if reportMalicious succeeded. But it looks like it doesn't.

Getting new validators from the active validators in the contract would not make an atomic validator set switch. The pending validators are enclosed in InitiateChange. When Parity receives that event, it changes its validator set and calls finalizeChange in the contract, so that the contract can update its active set of validators "atomically" (i.e. at the same time).

@varasev
Copy link

varasev commented Apr 23, 2019

Parity calls getValidators in several places, and that method should definitely return the new validator set if reportMalicious succeeded. But it looks like it doesn't.

Getting new validators from the active validators in the contract would not make an atomic validator set switch. The pending validators are enclosed in InitiateChange. When Parity receives that event, it changes its validator set and calls finalizeChange in the contract, so that the contract can update its active set of validators "atomically" (i.e. at the same time).

Yeah, but it is weird that the validators array is not changed by the reportMalicious:

@varasev
Copy link

varasev commented May 28, 2019

OK, now reportMalicious testing with afck-sim-malice is almost successful 🎉

The only thing we should add there is to call the ValidatorSet.isValidatorBanned getter in the on_close_block function along with the calling of ValidatorSet.maliceReportedForBlock:

let (data, decoder) = validator_set::functions::malice_reported_for_block::call(

So, first we should call the ValidatorSet.isValidatorBanned getter: if it returns true for the specified malicious_validator_address, we should remove a report from report cache like here:

Ok(ref reporters) if reporters.contains(&our_address) => {
trace!(target: "engine", "Successfully removed report from report cache");
false
}

If isValidatorBanned returns false, we should fallback to call the maliceReportedForBlock:

let (data, decoder) = validator_set::functions::malice_reported_for_block::call(

After this small improvement, I'll retest it and then we will merge the afck-test branch into aura-pos.

@varasev
Copy link

varasev commented May 30, 2019

Please add the following commits from the afck-sim-malice into afck-test branch:

@afck
Copy link
Collaborator Author

afck commented May 30, 2019

I squashed and pushed the changes.

@varasev
Copy link

varasev commented May 30, 2019

Ok, there is one unit test failure at the moment:

failures:

---- engines::validator_set::contract::tests::reports_validators stdout ----
thread 'engines::validator_set::contract::tests::reports_validators' panicked at 'assertion failed: `(left != right)`
  left: `[]`,
 right: `[]`', ethcore/src/engines/validator_set/contract.rs:233:3


failures:
    engines::validator_set::contract::tests::reports_validators

test result: FAILED. 290 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

@afck
Copy link
Collaborator Author

afck commented May 30, 2019

Right, sorry! We need to update the test contracts again: they don't have isValidatorBanned.

@varasev
Copy link

varasev commented May 30, 2019

Seems to be so. I tried to launch unit tests for the afck-sim-malice and see that this failure appeared on the commit 3cd22c0

Do you mean this test contract?

@afck
Copy link
Collaborator Author

afck commented May 30, 2019

Yes… I added the method and that fixed the test. But it's used in two places, and it somehow broke the other. I'm looking into that now…

@varasev
Copy link

varasev commented May 30, 2019

I think we should add there

mapping(address => bool) banned;

function isValidatorBanned(address _miningAddress) public view returns(bool) {
    return banned[_miningAddress];
}

and change the reportMalicious to

function reportMalicious(address validator, uint256 blockNum, bytes calldata) external {
    maliceReported[keccak256(abi.encode(validator, blockNum))].push(msg.sender);
    if (validators[indices[validator]] == validator) {
        banned[validator] = true;
        validators[indices[validator]] = validators[validators.length-1];
        delete indices[validator];
        delete validators[validators.length-1];
        validators.length--;
    }
}

@afck
Copy link
Collaborator Author

afck commented May 30, 2019

I pushed a more low-tech solution, but yours would more faithfully reproduce the production logic, of course. 👍
(Feel free to push your version, if you prefer to have proper banning logic in the tests.)

@varasev
Copy link

varasev commented May 30, 2019

Ok, I agree with your version and going to launch the unit tests for afck-test branch again...

@varasev
Copy link

varasev commented May 30, 2019

Seems that's OK now?

image

But it's used in two places, and it somehow broke the other. I'm looking into that now…

What other tests did you mean?

@afck
Copy link
Collaborator Author

afck commented May 30, 2019

The ones in ethcore/src/snapshot/tests/proof_of_authority.rs. (But I fixed the issue.)

Copy link

@varasev varasev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's merge it into aura-pos.

@phahulin phahulin removed their request for review May 30, 2019 11:01
@phahulin phahulin merged commit 86446a0 into aura-pos May 30, 2019
@afck afck deleted the afck-test branch May 30, 2019 12:03
afck added a commit that referenced this pull request Jul 24, 2019
This adds the malice report queue: Reports are included whenever we create a block ourselves, and they are also being resent as regular transactions until they have been successfully included in a block.

reportMalicious now matches the ABI used by the validator set code. It also checks whether the removed validator exists.

Squashed commits:
```
* Update the test validator set contract.

`reportMalicious` now matches the ABI used by the validator set code.
It also checks whether the removed validator exists.

* Add maliceReportedForBlock to test contract.

* Add back benign report check.

* Fix reportBenign ABI.

* Explicitly check malice report in the test.

* Queue malice reports

This is a squash of 18 commits:

Queue failed reports for later insertion into blocks

If we fail to send a transaction that reports a validator as malicious,
store it on a stack.  When we next seal a block, included the failed
transactions.

Insert our reports every time we prepare a block

Implement queued reporting

Prioritize the `emitInitiateChange` call

Fix warnings

These warnings cluttered build output, and made it hard to see actual
warnings in new code.

Implement (partial) cache purging.

Once an entry that cannot be purged is found, further entries are
skipped.

Finish report queuing

Use the correct reporting address

Drop reports beyond MAX_QUEUED_REPORTS

This helps prevent denial-of-service attacks.

Drop queued report limits

We now only keep 500 reports that have not been confirmed, or 100
reports that have been.

Lower limits on queued reports

Add a script to generate ABI files

and use it to fix compilation error due to incomplete ABI json.

Remove old validator reports

Reports over 100 blocks old are useless anyway.

Fix an unused variable warning in the test client

Show a better error when the validator set contract is bad

Fix backwards comparison between bad and current block numbers

Drop reports for block numbers ahead of the current one

Fix review comments from Andreas

Remove a commented-out constant, and use the standard library
`VecDeque::retain()` method instead of (inefficiently) reimplementing it
ourselves.

* Queue reports even if transaction creation was successful.

Having created a transaction doesn't guarantee that it will be
included in a block. We should queue the transaction anyway.

Also remove some unnecessary closures and match statements.

* Fix malice report nonce addr; disable transactions.

The nonce for malice reports needs to be the engine signer's, not the contract's.
Creating malice report transactions makes the `reports_validators` test hang,
so it is disabled for now.

* Make the unit tests work again.

* Retry sending queued malice reports.

* Fix malice report block numbers.

* added a constant to limit resending of returned reports

* skip at least one block when reporting malicious validators

* restored instantaneous malicious reports

* Filter malice reports more aggressively.

* Update test contracts: add isValidatorBanned.
```
afck added a commit that referenced this pull request Oct 7, 2019
This adds the malice report queue: Reports are included whenever we create a block ourselves, and they are also being resent as regular transactions until they have been successfully included in a block.

reportMalicious now matches the ABI used by the validator set code. It also checks whether the removed validator exists.

Squashed commits:
```
* Update the test validator set contract.

`reportMalicious` now matches the ABI used by the validator set code.
It also checks whether the removed validator exists.

* Add maliceReportedForBlock to test contract.

* Add back benign report check.

* Fix reportBenign ABI.

* Explicitly check malice report in the test.

* Queue malice reports

This is a squash of 18 commits:

Queue failed reports for later insertion into blocks

If we fail to send a transaction that reports a validator as malicious,
store it on a stack.  When we next seal a block, included the failed
transactions.

Insert our reports every time we prepare a block

Implement queued reporting

Prioritize the `emitInitiateChange` call

Fix warnings

These warnings cluttered build output, and made it hard to see actual
warnings in new code.

Implement (partial) cache purging.

Once an entry that cannot be purged is found, further entries are
skipped.

Finish report queuing

Use the correct reporting address

Drop reports beyond MAX_QUEUED_REPORTS

This helps prevent denial-of-service attacks.

Drop queued report limits

We now only keep 500 reports that have not been confirmed, or 100
reports that have been.

Lower limits on queued reports

Add a script to generate ABI files

and use it to fix compilation error due to incomplete ABI json.

Remove old validator reports

Reports over 100 blocks old are useless anyway.

Fix an unused variable warning in the test client

Show a better error when the validator set contract is bad

Fix backwards comparison between bad and current block numbers

Drop reports for block numbers ahead of the current one

Fix review comments from Andreas

Remove a commented-out constant, and use the standard library
`VecDeque::retain()` method instead of (inefficiently) reimplementing it
ourselves.

* Queue reports even if transaction creation was successful.

Having created a transaction doesn't guarantee that it will be
included in a block. We should queue the transaction anyway.

Also remove some unnecessary closures and match statements.

* Fix malice report nonce addr; disable transactions.

The nonce for malice reports needs to be the engine signer's, not the contract's.
Creating malice report transactions makes the `reports_validators` test hang,
so it is disabled for now.

* Make the unit tests work again.

* Retry sending queued malice reports.

* Fix malice report block numbers.

* added a constant to limit resending of returned reports

* skip at least one block when reporting malicious validators

* restored instantaneous malicious reports

* Filter malice reports more aggressively.

* Update test contracts: add isValidatorBanned.
```
@varasev varasev restored the afck-test branch October 18, 2019 12:33
@varasev varasev deleted the afck-test branch October 18, 2019 12:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix the validator set unit tests.
5 participants