# Supplementary Dataset README

## Study title

**Secure Electronic Voting System Based on Blockchain with Dilithium Authentication and Zero-Knowledge Proof Verification**

## Supplementary file

- **Dataset file:** `S1-Data.csv`
- **File format:** Comma-separated values (CSV)
- **Number of records:** 25,000
- **Number of variables:** 34
- **Data type:** Synthetic transaction-level experimental data

## Dataset overview

This supplementary dataset contains synthetic transaction-level records generated to represent the experimental evaluation of a permissioned blockchain-based electronic voting framework. The framework combines Dilithium-based post-quantum authentication, zero-knowledge-proof verification, encrypted ballot submission, nullifier-based duplicate-vote prevention, smart-contract validation, and Byzantine fault-tolerant consensus.

The dataset includes normal voting transactions, adversarial or invalid transaction scenarios, cryptographic processing measurements, blockchain finalization measurements, system-resource utilization, validation outcomes, and transaction acceptance or rejection results. It is provided to support transparency, statistical analysis, and reproducibility of the reported experimental evaluation.

The dataset does not contain real election data, real voter identities, private credentials, secret cryptographic keys, or personally identifiable information.

## Experimental composition

The dataset contains:

- **20,000** valid-vote transaction records.
- **5,000** adversarial or invalid transaction records.
- Five workload scenarios representing **50, 100, 250, 500, and 1,000 concurrent voters**.
- Simulated attack categories including duplicate nullifiers, forged signatures, modified encrypted ballots, modified zero-knowledge proofs, unregistered credentials, invalid candidate encodings, cross-election replay, expired-election transactions, and malformed transactions.

### Workload scenarios

| Scenario | Concurrent voters | Records | Mean throughput (TPS) | Mean finalization time (s) | Acceptance rate |
|---|---:|---:|---:|---:|---:|
| S1 | 50 | 5017 | 215.34 | 1.420 | 79.61% |
| S2 | 100 | 4981 | 332.24 | 1.730 | 80.12% |
| S3 | 250 | 5008 | 422.95 | 2.022 | 79.61% |
| S4 | 500 | 5014 | 495.94 | 2.452 | 79.34% |
| S5 | 1000 | 4980 | 549.67 | 3.275 | 79.56% |

The scenario-level values above are descriptive summaries calculated directly from the supplied CSV file.

## Variable dictionary

| Variable | Type | Description |
|---|---|---|
| `record_id` | String | Unique synthetic identifier assigned to each transaction record. |
| `scenario` | Categorical | Workload scenario label (`S1`–`S5`). |
| `run_id` | Integer | Identifier of the experimental run associated with the record. |
| `timestamp_utc` | Datetime string | Synthetic transaction timestamp expressed in Coordinated Universal Time. |
| `concurrent_voters` | Integer | Number of concurrently active voters represented in the workload scenario. |
| `transaction_type` | Categorical | Transaction class: `valid_vote` or `adversarial_transaction`. |
| `attack_category` | Categorical/blank | Simulated attack or invalid-transaction category. Blank for normal valid-vote records. |
| `candidate_id` | Integer | Synthetic candidate identifier. A value of `0` may denote an invalid or nonstandard candidate encoding in adversarial cases. |
| `credential_commitment_hash` | String | Synthetic hash representing the public commitment associated with a voter credential. |
| `nullifier_hash` | String | Synthetic nullifier hash used to test duplicate-vote prevention. |
| `ciphertext_hash` | String | Synthetic hash of the encrypted ballot payload. |
| `proof_hash` | String | Synthetic hash reference associated with the zero-knowledge proof. |
| `dilithium_key_reference` | String | Synthetic reference identifier for the Dilithium verification key. It is not a real private or public key. |
| `transaction_size_bytes` | Integer | Serialized transaction size measured in bytes. |
| `proof_generation_ms` | Numeric | Time required to generate the zero-knowledge proof, in milliseconds. |
| `proof_verification_ms` | Numeric | Time required to verify the zero-knowledge proof, in milliseconds. |
| `dilithium_signing_ms` | Numeric | Dilithium signing time, in milliseconds. |
| `dilithium_verification_ms` | Numeric | Dilithium signature-verification time, in milliseconds. |
| `nullifier_lookup_ms` | Numeric | Time required to check the nullifier registry, in milliseconds. |
| `smart_contract_update_ms` | Numeric | Smart-contract state-update time, in milliseconds. |
| `consensus_finalization_s` | Numeric | Time required to finalize the transaction or block through the consensus process, in seconds. |
| `end_to_end_latency_s` | Numeric | Overall transaction-processing latency, in seconds. |
| `throughput_tps` | Numeric | Observed processing throughput in transactions per second. |
| `cpu_utilization_pct` | Numeric | Simulated CPU utilization during transaction processing, expressed as a percentage. |
| `memory_gb` | Numeric | Simulated memory utilization, expressed in gigabytes. |
| `signature_valid` | Boolean | Indicates whether the Dilithium signature passed verification. |
| `proof_valid` | Boolean | Indicates whether the zero-knowledge proof passed verification. |
| `credential_registered` | Boolean | Indicates whether the credential commitment was present in the authorized registry. |
| `candidate_vector_valid` | Boolean | Indicates whether the encoded candidate selection satisfied the voting constraints. |
| `election_active` | Boolean | Indicates whether the transaction was submitted during the active election period. |
| `nullifier_unique` | Boolean | Indicates whether the submitted nullifier had not previously been used. |
| `accepted` | Boolean | Final transaction outcome: `True` for accepted and `False` for rejected. |
| `rejection_reason` | Categorical/blank | Reason for rejection. Blank when no rejection reason applies. |
| `synthetic_data_flag` | Boolean | Confirms that the record is synthetically generated. The value is `True` for all records. |

## Attack categories

The `attack_category` variable may contain the following values:

- `duplicate_nullifier`: repeated use of a previously submitted nullifier.
- `forged_dilithium_signature`: invalid or forged post-quantum signature.
- `modified_encrypted_ballot`: alteration of the encrypted ballot payload.
- `modified_zk_proof`: invalid or manipulated zero-knowledge proof.
- `unregistered_credential`: credential commitment absent from the authorized registry.
- `invalid_candidate_vector`: invalid candidate encoding or voting vector.
- `cross_election_replay`: replay of a transaction in a different election context.
- `expired_election_transaction`: transaction submitted outside the active election interval.
- `malformed_transaction`: structurally invalid transaction.

Blank values in `attack_category` correspond to valid-vote records and should not be interpreted as missing experimental information.

## Rejection reasons

The `rejection_reason` variable may contain the following values:

- `duplicate_nullifier`
- `invalid_signature`
- `ciphertext_integrity_failure`
- `invalid_zero_knowledge_proof`
- `credential_not_in_registry`
- `invalid_candidate_encoding`
- `election_binding_failure`
- `election_not_active`
- `malformed_transaction_structure`
- `queue_timeout_or_capacity_limit`

Blank values indicate that no rejection reason was assigned, usually because the transaction was accepted.

## Recommended loading procedure

### Python

```python
import pandas as pd

data = pd.read_csv("evoting_synthetic_dataset(1).csv", low_memory=False)
print(data.shape)
print(data.head())
```

### R

```r
data <- read.csv(
  "evoting_synthetic_dataset(1).csv",
  stringsAsFactors = FALSE
)

dim(data)
head(data)
```

## Basic validation checks

The following checks may be used after loading the file:

```python
assert data.shape[0] == 25000
assert data.shape[1] == 34
assert data["record_id"].is_unique
assert data["synthetic_data_flag"].eq(True).all()
assert set(data["transaction_type"].unique()) <= {
    "valid_vote",
    "adversarial_transaction"
}
```

Users may additionally verify that accepted transactions generally satisfy the signature, proof, credential, candidate-vector, election-status, and nullifier-validity conditions. Capacity-related rejection may occur even when cryptographic and logical validations succeed.

## Missing-value interpretation

The dataset contains intentionally blank values in two variables:

- `attack_category` is blank for normal valid-vote transactions.
- `rejection_reason` is blank where no rejection reason applies.

These blank entries are structurally meaningful and should not automatically be removed or imputed.

## Intended use

The dataset may be used for:

- reproducing descriptive and inferential statistical analyses;
- evaluating transaction latency and throughput under different workloads;
- analysing cryptographic and consensus-processing overhead;
- examining transaction acceptance and rejection behaviour;
- testing anomaly-detection or security-classification methods; and
- validating tables and figures reported in the associated study.

## Limitations

This is a synthetic dataset generated for controlled experimental evaluation. It should not be interpreted as evidence from a real public election or as a replacement for deployment-level testing. The recorded hashes and key references are synthetic identifiers and must not be treated as operational cryptographic artefacts. Real-world performance may vary according to hardware, network topology, consensus configuration, cryptographic implementation, smart-contract platform, and election scale.

## Ethical and privacy statement

No human participants, real voters, personal identifiers, actual ballot choices, biometric information, or private cryptographic material are included. Because all records are synthetic, the dataset does not permit identification of any individual voter.

## Citation

When using this supplementary dataset, please cite the associated article.