introducing Transaction Inspection Zone to block builder #459
Conversation
BEPs/BEP-467.md
Outdated
| - Proactive Vulnerability Response: in the event of an attack occuring it is crucial to act as quickly as possible, to do so protocols can registers actions for different situation beforehand, such as pausing protocol, disabling transfering of funds, etc. | ||
| - Builtin standard actions: rejecting transaction for the next block, notifying relavant parties, etc. | ||
|
|
||
| Once inspected, the cleared transactions are forwarded back to the block builder. |
There was a problem hiding this comment.
any design on validator side, like:
- what if a validator does not integrate MEV?
- or a validator do integrate with MEV but adopt local block eventually?
There was a problem hiding this comment.
Validators can integrate with this system independently.
Current design does not necessarily involve any changes to the consensus or Geth codebase. We believe such a design brings ease of adoption at the builder level and maintains the overall stability of the blockchain.
There was a problem hiding this comment.
this need all validator to integrate with the "TIZ", if one validator refuse to do so, the malicious tx will be included.
It it difficult to get every validator cooperate as this is not part of consensus rule.
|
This proposal may have the following risks: 1.Over-reliance on predefined rules: the proposal emphasizes pre-registered actions, but the complexity and diversity of attacks may exceed the scope of these predefined rules. For example, some attacks may exploit unforeseen vulnerabilities in the protocol, causing the standard actions to fail. Additionally, malicious transactions might evade detection through obfuscation. As a result, we cannot fully ensure the absence of false negatives or false positives. 2.Negative impact on user experience and protocol credibility: If these protective mechanisms are triggered in non-attack scenarios (e.g., mistakenly pausing the protocol or rejecting transactions), it may result in user funds being frozen or transactions failing, which could harm the protocol’s reputation. 3.Performance impact on on-chain operations: built-in standard actions, such as "rejecting transactions for the next block," need to closely integrate with block generation logic. This may lead to performance overhead or delays in transaction confirmation on-chain. In summary, the current design in the proposal may introduce instability to the blockchain. To advance this proposal, we may need a more detailed description of the mechanism, such as: 1.Enhancing dynamic response capabilities based on real-time status. For instance, after detecting an attack, the response strategy adjusts dynamically depending on the type of attack rather than relying solely on predefined actions. 2.Consider the impact of false positives. 3.Considering the efficiency of on-chain operations and the overall stability of the protocol. 4.Consider the technical complexity of the detection engine. |
No description provided.