Spider 2.0 Benchmark

When performing Ethereum blockchain data analysis for Spider 2.0, the following analytical objectives and data requirements must be met. The analysis focuses on address activity, balances, token transactions, general transaction patterns, mining rewards, contract creation, and failure/bytecode analysis up to January 1, 2017.

Core Analytical Domains

1. Address Activity

• Objective: Analyze activity patterns for each address.
• Consistency Metric (R_active_hour): For addresses with >24 activities, calculate hourly consistency using the root mean square of the sum of cosines and sines of transaction hours, normalized by transaction count.
• Active Days (active_days): Total count of days with activity.

2. Balance Analysis

• Objective: Compute net balance.
• Methodology: Use successful transactions only. Exclude specific Ethereum call types (delegatecall, callcode, staticcall) unless they are null.
• Calculation: (Tokens Received - Tokens Sent) - Transaction Fees.
• Scaling: Convert from Wei to Ether by dividing by $10^{18}$.

3. Token & General Transaction Analysis

• Token Metrics: Track incoming/outgoing transaction counts (token_in_tnx, token_out_tnx), token types (token_in_type, token_out_type), and distinct counterparties (token_from_addr, token_to_addr).
• General Metrics: Track trace counts (in_trace_count, out_trace_count), unique addresses (in_addr_count, out_addr_count), and non-zero value transfers (in_transfer_count, out_transfer_count).
• Gas Analysis: For incoming "call" type transactions, compute average gas used (avg_gas_used) and standard deviation (std_gas_used).

4. Mining, Contracts, and Failures

• Mining: Calculate reward_amount (scaled by $10^{18}$) excluding transaction fees.
• Contracts: Count contract_create_count and measure bytecode_size (length of bytecode).
• Failures: Count failure_count (failed transactions initiated by the address).

In the Spider 2.0 dataset, laps are categorized into specific types to describe the context of a driver's performance or status during a race. When querying or analyzing race data, you can use these types to distinguish between active racing, starting position changes, and various forms of retirement.

Race Laps

• Race: Laps completed during the actual race period by participating drivers.

Starting Position Types

These types describe the relationship between a driver's qualifying position and their actual starting position on the grid:

• Starting Position - Grid Increase: The driver started in a better position than they qualified.
• Starting Position - Qualifying: The driver started in the exact position they achieved during qualifying.
• Starting Position - Grid Drop: The driver started in a worse position than they qualified (e.g., due to penalties).

Retirement Types

These types indicate why a driver failed to complete the race:

• Retirement (Driver Error): Exit due to driver mistakes, such as crashes or loss of control.
• Retirement (Mechanical Problem): Exit due to technical or engine failures.
• Retirement (Disqualification): Exit due to rule violations or regulatory exclusion.

The Spider 2.0 dataset uses an Overlap Ratio method to estimate the number of bank institutions per ZIP code. This method resolves the spatial mismatch between ZIP code boundaries and Census Block Groups through a three-step process:

1. Geospatial Intersection: Calculate the area of intersection between a ZIP Code Area geometry and a Census Block Group geometry. The overlap ratio is defined as: $$ ext{overlap ratio} = \frac{\text{Intersection Area (ZIP $\cap$ Block Group)}}{\text{Total Area (Block Group)}}$$
2. Bank Distribution: Distribute bank locations to Census Block Groups based on this ratio. The number of bank locations in a block group is proportionally assigned based on how much of that block group falls within a specific ZIP code.
3. Aggregation: Aggregate the distributed values by ZIP code to determine the final count of bank institutions per postal code area.

The Timberland Acres data model is used to analyze forest plots based on productivity and current status. It includes specific attributes for identification, regional analysis, and temporal tracking, as well as conditional area calculations.

Key Attributes

• plot_sequence_number: Unique identifier for each plot.
• evaluation_type: Must be EXPCURR for current evaluations.
• evaluation_group: Classification for organizing data by evaluation cycles.
• evaluation_description: Details on the purpose/scope of the evaluation.
• plot_state_code_name (state_name): The name of the state for regional reporting.
• state_code: Numerical or textual code for filtering/aggregation.
• inventory_year: The year of data collection.

Area Calculations

Area is calculated conditionally based on the proportion basis:

• macroplot_acres: Used when proportion basis is 'MACR' and adjustment_factor_for_the_macroplot > 0.
  • Formula: p.expansion_factor * c.condition_proportion_unadjusted * p.adjustment_factor_for_the_macroplot
• subplot_acres: Used when proportion basis is 'SUBP' and adjustment_factor_for_the_subplot > 0.
  • Formula: p.expansion_factor * c.condition_proportion_unadjusted * p.adjustment_factor_for_the_subplot

Required Filter Conditions

To ensure valid analysis, apply these filters:

• condition_status_code = 1 (active conditions only)
• reserved_status_code = 0 (exclude reserved plots)
• site_productivity_class_code must be between 1 and 6.

Spider 2.0 uses a geospatial overlap method to estimate the number of bank institutions within specific postal code areas (ZIP codes). Because ZIP code boundaries and census block groups do not align perfectly, the system uses an overlap ratio to distribute bank location data accurately.

The calculation follows three main steps:

1. Geospatial Intersection: Calculate the area of intersection between ZIP Code Areas and Census Block Groups. The overlap ratio is defined as: $$\text{overlap ratio} = \frac{\text{Area of Intersection (ZIP $\cap$ Block Group)}}{\text{Total Area of Block Group}}$$

2. Bank Location Distribution: Distribute the number of bank locations to census block groups based on the calculated overlap ratio. This ensures that bank institutions are proportionally assigned to the block groups that fall within a specific ZIP code.

3. Aggregation: Aggregate the distributed values by ZIP code to determine the total number of bank institutions per postal code area.

The CrossDomainEnabled contract is a helper used by both L1 and L2 bridges to facilitate communication between layers. It relies on a messenger (an ICrossDomainMessenger) to send and receive messages.

Security Model

To prevent unauthorized messages from being processed, the contract uses the onlyFromCrossDomainAccount modifier. This modifier ensures that:

1. The msg.sender is the authenticated messenger contract.
2. The xDomainMessageSender() (the account that initiated the message on the other domain) matches the expected _sourceDomainAccount (e.g., the bridge contract on the other side).

Sending Messages

Use the sendCrossDomainMessage function to dispatch data to a target address on the other domain. This is typically used to trigger functions on the destination layer via the cross-domain messenger.

contract CrossDomainEnabled {
    address public messenger;

    constructor(address _messenger) {
        messenger = _messenger;
    }

    modifier onlyFromCrossDomainAccount(address _sourceDomainAccount) {
        require(msg.sender == address(getCrossDomainMessenger()), "OVM_XCHAIN: messenger contract unauthenticated");
        require(getCrossDomainMessenger().xDomainMessageSender() == _sourceDomainAccount, "OVM_XCHAIN: wrong sender of cross-domain message");
        _;
    }

    function sendCrossDomainMessage(
        address _crossDomainTarget,
        uint32 _gasLimit,
        bytes memory _message
    ) internal {
        getCrossDomainMessenger().sendMessage(_crossDomainTarget, _message, _gasLimit);
    }
}