-
Notifications
You must be signed in to change notification settings - Fork 176
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #4652 from onflow/yahya/6857-bft-testing-ci-fix-2
[BFT Testing] Reducing load of BFT tests and improving test packages
- Loading branch information
Showing
29 changed files
with
314 additions
and
168 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
package testnet_test | ||
|
||
import ( | ||
"testing" | ||
|
||
"github.com/stretchr/testify/assert" | ||
|
||
"github.com/onflow/flow-go/integration/testnet" | ||
"github.com/onflow/flow-go/model/flow" | ||
) | ||
|
||
func TestFilter(t *testing.T) { | ||
t.Run("filters by role", func(t *testing.T) { | ||
configs := testnet.NewNodeConfigSet(5, flow.RoleAccess) | ||
|
||
// add another role to the set to ensure it is filtered out | ||
configs = append(configs, testnet.NewNodeConfig(flow.RoleExecution)) | ||
filters := configs.Filter(func(n testnet.NodeConfig) bool { return n.Role == flow.RoleAccess }) | ||
assert.Len(t, filters, 5) // should exclude execution node | ||
for _, config := range filters { | ||
assert.Equal(t, flow.RoleAccess, config.Role) | ||
} | ||
}) | ||
|
||
t.Run("filters by multiple conditions", func(t *testing.T) { | ||
configs := testnet.NodeConfigs{ | ||
testnet.NewNodeConfig(flow.RoleAccess, testnet.WithDebugImage(true)), | ||
testnet.NewNodeConfig(flow.RoleExecution, testnet.WithDebugImage(true)), | ||
} | ||
|
||
filters := configs.Filter( | ||
func(n testnet.NodeConfig) bool { return n.Role == flow.RoleAccess }, | ||
func(n testnet.NodeConfig) bool { | ||
return n.Debug | ||
}, | ||
) | ||
|
||
assert.Len(t, filters, 1) // should exclude execution node | ||
assert.True(t, filters[0].Debug) | ||
}) | ||
|
||
t.Run("no matching filters", func(t *testing.T) { | ||
configs := testnet.NewNodeConfigSet(5, flow.RoleConsensus) | ||
|
||
filters := configs.Filter(func(n testnet.NodeConfig) bool { return n.Role == flow.RoleAccess }) | ||
|
||
assert.Len(t, filters, 0) | ||
}) | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Framework BFT Tests | ||
The framework BFT tests are designed to assess the health of the BFT testing framework. | ||
|
||
## Passthrough Sealing and Verification Test | ||
The `PassThroughTestSuite` test within the `framework` package includes a specific test method `TestSealingAndVerificationPassThrough`. | ||
This test evaluates the health of the BFT testing framework for Byzantine Fault Tolerance (BFT) testing. | ||
1. **Simulates a Scenario**: It sets up a scenario with two corrupt execution nodes and one corrupt verification node, controlled by a dummy orchestrator that lets all incoming events pass through. | ||
2. **Deploys Transaction and Verifies Chunks**: Deploys a transaction leading to an execution result with multiple chunks, assigns them to a verification node, and verifies the generation of result approvals for all chunks. | ||
3. **Sealing and Verification**: Enables sealing based on result approvals and verifies the sealing of a block with a specific multi-chunk execution result. | ||
4. **Evaluates Events**: The test also assesses whether critical sealing-and-verification-related events from corrupt nodes are passed through the orchestrator, by checking both egress and ingress events. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
# GossipSub BFT Tests | ||
GossipSub BFT tests are designed to test the behavior of the GossipSub protocol in a network environment with Byzantine nodes. | ||
|
||
## Topic Validator Test | ||
The `TopicValidatorTestSuite` in the `topicvalidator` package is specifically designed to test the functionality of the | ||
libp2p topic validator within a network scenario. | ||
This suite includes an end-to-end test to verify the topic validator's behavior in different situations, | ||
focusing on both unauthorized and authorized message handling. | ||
The method `TestTopicValidatorE2E` is a comprehensive test that mimics an environment with a corrupt byzantine attacker node | ||
attempting to send unauthorized messages to a victim node. | ||
These messages should be dropped by the topic validator, as they fail the message authorization validation. | ||
The test simultaneously sends authorized messages to the victim node, ensuring that they are processed correctly, | ||
demonstrating the validator's correct operation. | ||
The test confirms two main aspects: | ||
1. Unauthorized messages must be dropped, and the victim node should not receive any of them. | ||
2. Authorized messages should be correctly delivered and processed by the victim node. | ||
|
||
## Signature Requirement Test | ||
The `TestGossipSubSignatureRequirement` test sets up a test environment consisting of three corrupt nodes: two attackers and one victim. | ||
One (malicious) attacker is configured without message signing, intending to send unsigned messages that should be rejected by the victim. | ||
The other (benign) attacker sends valid signed messages that should be received by the victim. | ||
The test is broken down into the following main parts: | ||
1. **Unauthorized Messages Testing**: The victim node should not receive any messages sent without correct signatures from the unauthorized attacker. The test checks for zero unauthorized messages received by the victim. | ||
2. **Authorized Messages Testing**: Messages sent by the authorized attacker, with the correct signature, must pass the libp2p signature verification process and be delivered to the victim. The test checks for all authorized messages received by the victim within a certain time frame. | ||
|
||
## RPC Inspector False Positive Test | ||
The `GossipsubRPCInspectorFalsePositiveNotificationsTestSuite` test within the `rpc_inspector` package test suite aims to ensure that the underlying libp2p libraries related to GossipSub RPC control message inspection do not trigger false positives during their validation processes. | ||
Here's a breakdown of the `TestGossipsubRPCInspectorFalsePositiveNotifications` method: | ||
1. **Configuration and Context Setup**: A specific duration for loading and intervals is defined, and a context with a timeout is created for the test scenario. | ||
2. **Simulating Network Activity**: The method triggers a "loader loop" with a specific number of test accounts and intervals, intending to create artificial network activity. It does this by submitting transactions to create Flow accounts, waiting for them to be sealed. | ||
3. **State Commitments**: The method waits for 20 state commitment changes, ensuring that the simulated network load behaves as expected. | ||
4. **Verification of Control Messages**: After simulating network activity, the method checks to ensure that no node in the network has disseminated an invalid control message notification. This is done by collecting metrics from the network containers and verifying that no false notifications are detected. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
# Protocol BFT Tests | ||
This package contains BFT tests concerning the core Flow protocol. These tests are run as part of the integration test suite. | ||
|
||
|
||
## Admin Command Disallow List Test | ||
The `AdminCommandDisallowListTestSuite` in the `disallowlisting` package is designed to test the functionality of the disallow-list admin command within a network context. | ||
It ensures that connections to a blocked node are immediately pruned and incoming connection requests are blocked. | ||
The test simulates the setup of two corrupt nodes (a sender and a receiver) and examines the behavior of the network before and after the sender node is disallowed. | ||
It includes steps to send authorized messages to verify normal behavior, implement disallow-listing, send unauthorized messages, and validate the expectation that no unauthorized messages are received. | ||
Various timing controls are put in place to handle asynchronous processes and potential race conditions. | ||
The entire suite assures that the disallow-listing command behaves as intended, safeguarding network integrity. | ||
|
||
## Wintermute Attack Test | ||
The `WintermuteTestSuite` in the `wintermute` package is focused on validating a specific attack scenario within the network, termed the "wintermute attack." | ||
This attack involves an Attack Orchestrator corrupting an execution result and then leveraging corrupt verification nodes to verify it. | ||
The suite includes a constant timeout to define the attack window and a detailed test sequence. | ||
The `TestWintermuteAttack` method carries out the attack process. | ||
It first waits for an execution result to be corrupted and identifies the corresponding victim block. | ||
It ensures that the corrupt execution nodes generate the correct result for the victim block and then waits for a specific number of approvals from corrupt verification nodes for each chunk of the corrupted result. | ||
Further, the test waits for a block height equal to the victim block height to be sealed and verifies that the original victim block is correctly identified. | ||
Additional methods and logging information assist in detailing and controlling the flow of the attack. | ||
The entire suite is instrumental in evaluating the system's behavior under this specific attack condition and ensuring that the expected actions and responses are observed. |
Oops, something went wrong.