Abstract

GoPlus Security Module (GSM) can be natively integrated into customized BNB Chain node clients
In a reproduction test of 100 real attack transactions, GSM successfully intercepted 97 - a detection rate of 97%
Over the past year, it could prevent user asset losses of more than $22 million

After integration, single transaction delay increases by <40ms, with zero crashes under 1000 TPS pressure
Unlike wallet or API solutions, GSM cannot be bypassed, intercepting before the transaction enters the memory pool

GSM: A Security Firewall on the Blockchain Client Side

GSM is a lightweight modular SDK or API service that can be embedded in wallets, dApps, RPC services, Layer 2 sequencers, and full nodes. Its core is establishing a bridge between user transactions and the GoPlus security service network:

1. When a transaction is triggered, GSM captures transaction data and sends it to the GoPlus security network;
2. GoPlus analyzes risks in real-time through AI algorithms (including transaction data and user security policies);
3. Returns a security assessment result, and GSM executes release or interception operations.

Unlike traditional Web2 security solutions, GSM is directly built on the blockchain layer, forming a security isolation boundary between on-chain and off-chain environments. This architecture:
· Eliminates dependence on external Web2 facilities;

· Solves the weakest link in traditional security;

· Protects user assets even if the Web2 layer UI/UX is breached.

GSM's Two-Phase Transaction Filtering Mechanism

1️⃣ Pre-Memory Pool Transaction Screening (Sentinel Defense)

When a transaction is submitted through RPC calls like eth_sendRawTransaction, GSM scans instantly before entering the memory pool:
· Objective: Intercept clearly malicious transactions (such as blacklisted addresses, known malicious contract interactions)

· Advantages: Prevent harmful transaction propagation, reduce memory occupation, save node resources

2️⃣ Pre-Packaging Context Batch Analysis

Triggered before the transaction transitions from queued state to pending state:

· Objective: Perform context-aware deep analysis of transaction sequences (grouped and sorted by from address and nonce)

· Capabilities:
Detect complex vulnerability exploits like multi-step reentry attacks;
Identify fraudulent sequences across multiple transactions (such as false liquidity injection and withdrawal);
Assess batch transaction risks through cumulative risk scoring (impossible with single transaction analysis)

Smart Cache Layer

Store recent scan results to avoid repeated analysis of high-frequency benign activities - ensuring high throughput and low latency.

Open Source Address

The modified BNBChain node client and test data are open-sourced, available here.

Risk Detection Model: 12+ Dimensional Features

GSM evaluates transactions through a multi-factor weighted scoring model:

Output risk score (0-100) and disposal strategy:

· 0-20: Low risk → Release

· 21-60: Medium risk → Mark

· 61-100: High risk → Intercept (default)

Performance Benchmark Test: gRPC Interface

GSM provides two high-performance interfaces:

· EVMRiskScore (single transaction assessment)
· EVMBatchRiskScore (batch transaction analysis)

Test Environment

· Network: BNBChain Chapel Testnet

· Hardware:
8-core CPU
16GB RAM
500GB NVMe SSD
· Software:

BNBChain Full Node (v1.1.18) + GSM Module
· Load Tools:

Parallel gRPC Client Simulator
Latency Performance Profiler
GoPlus Historical Attack Scenario Reproduction Test Suite

Open Source Address

Modified BNBChain node and experimental data, available here.

Real Attack Detection Test: 100 Vulnerability Exploit Transactions

Test Method:

1. Select 100 BNBChain historical attack transactions (2024.4-2025.5)
2. Rebuild account and block states on Chapel Testnet
3. Replay transactions through GSM node
4. Record GSM decisions and scores
5. Data sources: ScamSniffer, CyversAlerts, and 10 other security agencies

Attack Case Analysis

Case #1: Phishing Authorization Trap

· Type: Fake airdrop website + Malicious "approve" authorization
· Risk Score: 100
· Features:
Phishing score: 82
Receiving address risk: 82
Function pattern: Unlimited authorization
User behavior anomaly value: 23

→ Intercepted

Case #2: Honeypot Token (Buy-only)

· Type: Token that users can buy but cannot sell
· Risk Score: 100
· Features:
Runaway score: 100
Receiving address risk: 68
Abnormal input amount: 24
→ Intercepted

Case #3: DeFi Contract Vulnerability Exploit

· Type: Hacker exploiting reentry vulnerability through underlying call
· Risk Score: 100
· Features:
Vulnerability pattern matching: 90
Initiating address risk tag: 90
Call data pattern anomaly: 82
→ Intercepted

Call to Action

Security protection should not be reactive. GSM proves: Without modifying the consensus mechanism, malicious transactions can be intercepted before taking effect!

We call on the following participants to deploy GSM as the default security layer:

· L1/L2 Blockchain Teams

· Rollup-as-a-Service (RaaS) Providers

· RPC Node Providers

· DApp and Wallet Infrastructure Teams

Try it now: service@gopluslabs.io; Documentation

Click to learn about BlockBeats job openings

Welcome to join the BlockBeats official community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia