[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-73988":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":15,"stars30d":15,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":16,"rankGlobal":9,"rankLanguage":9,"license":17,"archived":18,"fork":18,"defaultBranch":19,"hasWiki":20,"hasPages":18,"topics":21,"createdAt":9,"pushedAt":9,"updatedAt":22,"readmeContent":23,"aiSummary":24,"trendingCount":15,"starSnapshotCount":15,"syncStatus":25,"lastSyncTime":26,"discoverSource":27},73988,"quip-protocol","QuipNetwork\u002Fquip-protocol","QuipNetwork","experimental quip protocol network node",null,"Python",11640,159,33,11,0,41.61,"GNU Affero General Public License v3.0",false,"main",true,[],"2026-06-12 02:03:20","# Quip Network Experimental Node\n\n> **WARNING: This is experimental demonstration software provided without warranty of any kind. It is not intended for production use. Use at your own risk.**\n\nThis project implements a quantum blockchain using quantum annealing for proof-of-work consensus. It features competitive mining between quantum computers (QPU) and classical simulated annealing (SA) with a dynamic difficulty adjustment mechanism.\n\n## Overview\n\nThe blockchain demonstrates:\n\n- **Quantum Annealing PoW**: Using Ising model optimization as the mining puzzle\n- **Competitive Mining**: Multiple miners (QPU and SA) compete to mine blocks\n- **Multi-Miner Support**: Configure any number of QPU and SA miners\n- **Dynamic Difficulty**: Inverted difficulty mechanism that prevents miner monopolization\n- **Streak Rewards**: Consecutive wins increase block rewards\n- **Solution Diversity**: Requires multiple diverse solutions to prevent trivial mining\n- **Individual Miner Tracking**: Each miner has unique ID and performance stats\n\n## Current Scope\n\nThe current implementation:\n- **Quantum PoW only** - No transactions, accounts, or other typical blockchain features\n- **Demonstration signatures** - The signature system is not yet production-secure; it demonstrates the hybrid ECDSA + WOTS+ approach but requires proper integration\n\n## Roadmap\n\nWe plan to build a complete blockchain by forking an existing battle tested codebase to maximize development velocity.\n\n### Phase 1: Core Integration\n- Fork a battle-tested blockchain codebase\n- Integrate our quantum proof-of-work mechanism (Ising model optimization, difficulty adjustment, block time targets already defined)\n- Target: Testnet deployment\n\n### Phase 2: Signature System\n- Integrate our hybrid signature system: classical ECDSA combined with post-quantum WOTS+ signatures\n- Implement stateful signature management\n- Wire signatures into transaction processing and consensus\n\n### Phase 3: Subnet Architecture\n- Implement a subnet system with **objective, measurable metrics** for validation\n- Subnets will solve computational problems (scientific computing, cryptographic proofs, etc.) with verifiable results\n- Define subnet registration, validation mechanisms, and reward distribution\n\n### Phase 4: Smart Contracts\n- Add smart contract support via EVM compatibility (Solidity\u002FVyper) and\u002For Rust-based WebAssembly runtime\n- Later: Enable contracts to interact with subnet computational results\n\n### Open Technical Decisions\n1. Which blockchain codebase to fork?\n2. How to structure subnets for different computational problem types?\n3. How to validate objective metrics across the decentralized network?\n4. Performance targets (TPS, finality time, subnet throughput)?\n\n## Getting Started\n\nYou can run your own node using the \"latest\" release, see the README in the `docker` directory for instructions on how to run the node in a container.\n\n## Setup\n\n1. Create and activate a virtual environment (Python 3.10+):\n\n   ```bash\n   python3 -m venv .quip\n   source .quip\u002Fbin\u002Factivate  # Windows: .venv\\Scripts\\activate\n   ```\n\n2. Install the package in editable mode:\n\n   ```bash\n   pip install -U pip setuptools wheel\n   pip install -e .\n   ```\n\n   This will install all dependencies from pyproject.toml and register console scripts.\n\n3. Set up D-Wave API credentials (optional, for QPU access):\n   ```bash\n   echo \"DWAVE_API_KEY=your_api_key_here\" > .env\n   ```\n\n## Project Structure\n\n```\nquip-protocol\u002F\n├── quip_cli.py                # Main CLI entry point\n├── blockchain_base.py         # Base classes for miners\n├── shared\u002F                    # Core modules\n│   ├── network_node.py       # P2P networking (QUIC protocol)\n│   ├── node.py               # Node state management\n│   ├── block.py              # Block and header dataclasses\n│   ├── block_signer.py       # ECDSA + WOTS+ signatures\n│   ├── quantum_proof_of_work.py  # Ising model PoW\n│   ├── base_miner.py         # Abstract miner interface\n│   └── ...                   # Additional utilities\n├── CPU\u002F                       # CPU-based miners\n│   ├── sa_miner.py           # Simulated annealing miner\n│   └── sa_sampler.py         # SA sampler implementation\n├── GPU\u002F                       # GPU-accelerated miners\n│   ├── cuda_miner.py         # CUDA GPU miner\n│   ├── metal_miner.py        # Apple Metal\u002FMPS miner\n│   └── modal_miner.py        # Modal Labs cloud GPU\n├── QPU\u002F                       # Quantum processor miners\n│   ├── dwave_miner.py        # D-Wave QPU miner\n│   └── dwave_sampler.py      # D-Wave sampler wrapper\n├── docker\u002F                    # Docker deployment files\n├── tests\u002F                     # Test suite\n├── reference\u002F                 # Reference implementation\n└── benchmarks\u002F                # Performance benchmarks\n```\n\n## quip-network-node\n\nRun a single P2P node of a specific type. Subcommands: cpu, gpu, qpu.\n\n- Always enables competitive mode\n- Implies a single miner of that type (num-sa\u002Fnum-gpu\u002Fnum-qpu = 1)\n- Supports a top-level --config TOML that can choose a default subcommand\n- Global settings provide host, port, peer, and auto_mine\n- CPU supports --num-cpus to cap threads via OMP\u002FMKL\u002FBLAS env vars\n- GPU supports multi-device via [gpu] in TOML (backend=local|modal); --device forces single device\n- QPU supports D-Wave settings via CLI or TOML under [qpu]\n\nExamples:\n\n```bash\n# CPU node (bootstrap), limit to 4 threads\nquip-network-node cpu --port 8080 --num-cpus 4\n\n# GPU node joining bootstrap with device 0\nquip-network-node gpu --port 8082 --peer localhost:8080 --device 0\n\n# Use TOML config to choose default subcommand and flags\nquip-network-node --config .\u002FQUIP-node.example.toml\n\n# Modal backend example via TOML\n# [gpu]\n# backend = \"modal\"\n# types = [\"t4\", \"a10g\"]\n```\n\nTOML structure:\n\n```toml\n[global]\ndefault = \"gpu\"  # or \"cpu\"\u002F\"qpu\"\n# Global network options\nhost = \"0.0.0.0\"\nport = 8082\npeer = \"localhost:8080\"\nauto_mine = 0\n\n[cpu]\n# Limit CPU worker threads; max is number of logical CPUs\nnum_cpus = 4\n\n[gpu]\n# Backend selection: \"local\" (default) uses local GPUs (CUDA\u002FROCm\u002FMPS). \"modal\" uses Modal cloud GPUs.\nbackend = \"local\"\n# For local backend: list devices to use (CUDA ordinals like \"0\", \"1\"). If omitted, runtime may auto-detect.\ndevices = [\"0\", \"1\"]\n# For modal backend: list GPU types to use (e.g., [\"t4\", \"a10g\"]).\n# types = [\"t4\", \"a10g\"]\n\n[qpu]\n# Provide any of these to configure D-Wave access; can also pass on CLI\n# dwave_api_key = \"...\"\n# dwave_api_solver = \"Advantage_system6.4\"\n# dwave_region_url = \"https:\u002F\u002Fna-west-1.cloud.dwavesys.com\u002Fsapi\u002Fv2\u002F\"  # default\n```\n\nSee a working example in QUIP-node.example.toml.\n\n### quip-network-simulator\n\nLaunches multiple nodes for testing different network scenarios:\n\n```bash\n# Mixed (approx. 3 CPU, 2 GPU, 1 QPU)\nquip-network-simulator --scenario mixed\n\n# CPU-only with 4 nodes\nquip-network-simulator --scenario cpu\n\n# GPU-only with overrides and base port (print only)\nquip-network-simulator --scenario gpu --num-gpu 2 --base-port 9000 --print-only\n```\n\n## Deployment\n\n> **Recommended:** Use the **[Quip Node Manager](https:\u002F\u002Fgitlab.com\u002Fquip.network\u002Fquip-node-manager)** to run a quip node.\n>\n> For remote server deployment with Docker, see **[nodes.quip.network](https:\u002F\u002Fgitlab.com\u002Fquip.network\u002Fnodes.quip.network)**.\n\n| Method | Directory | Description |\n|--------|-----------|-------------|\n| **Docker** | [`docker\u002F`](docker\u002F) | Containerized deployment (CPU and CUDA images) |\n| **Systemd** | [`systemd-linux\u002F`](systemd-linux\u002F) | Bare-metal Linux with systemd (unsupported, convenience only) |\n| **PyInstaller** | [`pyinstaller\u002F`](pyinstaller\u002F) | Build standalone binaries |\n\n## Usage\n\n# Single-node blockchain\n\nUse these to test blockchain mining in an isolated single-node network on different platforms.\n\n# CPU node\n\n```\nquip-network-node cpu --listen 127.0.0.1 --port 8085 --public-host 127.0.0.1:8085 --auto-mine --peer 127.0.0.1:8085 --genesis-config genesis_block_public.json\n```\n\n# GPU node (CUDA)\n\n```\nquip-network-node gpu --listen 127.0.0.1 --port 8085 --public-host 127.0.0.1:8085 --auto-mine --peer 127.0.0.1:8085 --gpu-backend local --genesis-config genesis_block_public.json\n```\n\n# Mac Metal node\n\n```\nquip-network-node gpu --listen 127.0.0.1 --port 8085 --public-host 127.0.0.1:8085 --auto-mine --peer 127.0.0.1:8085 --gpu-backend mps --genesis-config genesis_block_public.json\n```\n\n### Run Performance Benchmarks\n\n```bash\npython benchmarks\u002Fbenchmark_quantum_pow.py\n```\n\nGenerates comprehensive benchmarks comparing QPU vs SA performance:\n\n![Performance Metrics](benchmarks\u002Fperformance_metrics.png)\n![Energy Distributions](benchmarks\u002Fenergy_distributions.png)\n\n## Quantum Proof-of-Work Mechanism\n\n### Core Concepts\n\n1. **Ising Model Generation**: Each block generates a unique Ising problem based on:\n\n   - Block header hash\n   - Mining nonce\n   - Deterministic random seed\n\n2. **Solution Requirements**:\n\n   - **Energy Threshold**: Solutions must have energy \u003C difficulty_energy\n   - **Solution Diversity**: Multiple solutions with minimum Hamming distance\n   - **Minimum Solutions**: At least N valid solutions required\n\n3. **Mining Process**:\n   - Miners iterate through nonces\n   - For each nonce, sample the quantum annealer\n   - Check if solutions meet all criteria\n   - First miner to find valid solutions wins\n\n### Dynamic Difficulty (Inverted Mechanism)\n\nThe blockchain implements an inverted difficulty adjustment:\n\n```\nInitial State: HARD (QPU-favored)\n├── Energy: -1150\n├── Diversity: 0.45\n└── Solutions: 15\n\nConsecutive Wins → EASIER\n└── Reduces requirements progressively\n\nNew Winner → HARDER\n└── Increases difficulty based on previous streak\n```\n\nThis mechanism:\n\n- Starts with QPU-favorable difficulty\n- Makes mining easier for consecutive winners\n- Immediately hardens when a new miner wins\n- Prevents long-term monopolization\n\n### Competitive Mining Results\n\nThe inverted difficulty mechanism produces balanced mining distribution:\n\n![Blockchain Mining Results](benchmarks\u002Fblockchain_benchmark_comprehensive.png)\n\nKey outcomes:\n\n- **QPU**: ~70% of blocks (leverages quantum advantage initially)\n- **SA**: ~30% of blocks (catches up as difficulty eases)\n- **Streak Rewards**: Up to 5x multiplier for consecutive wins\n- **Dynamic Balance**: Self-adjusting difficulty maintains competition\n\n![Mining Time Analysis](benchmarks\u002Fblockchain_benchmark_timing.png)\n\n## Technical Parameters\n\n### Shared Mining Parameters\n\n```python\ndifficulty_energy = -1000.0  # Energy threshold\nmin_diversity = 0.28         # Solution diversity requirement\nmin_solutions = 10           # Minimum valid solutions\n```\n\n### Miner-Specific Settings\n\n- **QPU**: Uses D-Wave quantum processor (when available)\n- **SA**: num_sweeps=4096 for optimal performance\n- **Both**: 64 reads per mining attempt\n\n### Difficulty Adjustment\n\n```python\nenergy_adjustment_rate = 0.10  # 10% change per streak level\nmax_streak_multiplier = 5      # Maximum reward multiplier\n```\n\n## Key Features\n\n1. **Decentralized Consensus**: All miners use identical difficulty parameters\n2. **Quantum-Classical Competition**: Fair competition between QPU and SA\n3. **Anti-Monopolization**: Dynamic difficulty prevents single miner dominance\n4. **Performance Monitoring**: Comprehensive metrics and visualizations\n5. **Solution Quality**: Enforces diversity to prevent trivial solutions\n\n## GPU Mining Support\n\nThe blockchain supports GPU-accelerated mining using Modal Labs cloud infrastructure, providing a cost-effective middle ground between CPU-based SA miners and QPU miners.\n\n### GPU Mining Setup\n\n1. **Install Modal** (includes $30\u002Fmonth free credits):\n\n   ```bash\n   pip install modal\n   modal token new  # Opens browser for authentication\n   ```\n\n2. **Run GPU Node**:\n\n   ```bash\n   # Local CUDA GPU\n   quip-network-node gpu --gpu-backend local --auto-mine\n\n   # Modal Labs cloud GPU\n   quip-network-node gpu --gpu-backend modal --auto-mine\n   ```\n\n### GPU Types and Performance\n\n| GPU Type | Cost\u002FHour | Performance vs SA | Best Use Case         |\n| -------- | --------- | ----------------- | --------------------- |\n| T4       | ~$0.10    | 3x faster         | Cost-conscious mining |\n| A10G     | ~$0.30    | 8x faster         | Balanced performance  |\n| A100     | ~$1.00    | 25x faster        | Maximum performance   |\n\n### GPU Mining Features\n\n- **CUDA Acceleration**: Uses CuPy for GPU-optimized annealing\n- **Automatic Fallback**: Falls back to SA if GPU unavailable\n- **Individual Tracking**: Each GPU miner has unique ID (GPU-1, GPU-2, etc.)\n- **Color Coding**: GPU miners shown in green shades in benchmark plots\n- **Cost Optimization**: Start with T4, scale up as needed\n\n### GPU Benchmarking\n\nRun standalone GPU benchmarks:\n\n```bash\nmodal run benchmarks\u002Fgpu_benchmark_modal.py\n```\n\nThis compares different GPU types and provides cost\u002Fperformance analysis.\n\n## P2P Network\n\nThe blockchain uses QUIC protocol for peer-to-peer communication with built-in TLS 1.3 encryption.\n\n### Features\n\n- **QUIC Protocol**: Low-latency UDP-based transport with TLS 1.3\n- **Automatic Node Discovery**: Nodes broadcast new peers to the network\n- **Heartbeat Mechanism**: 15s interval, 60s timeout for liveness\n- **Block Propagation**: New blocks broadcast via GOSSIP messages\n- **Chain Synchronization**: Automatic sync with peers on join\n\n### Protocol Messages\n\nThe QUIC protocol uses binary message types:\n- `JOIN_REQUEST` \u002F `JOIN_RESPONSE`: Node discovery\n- `HEARTBEAT`: Liveness checks\n- `GOSSIP`: Block propagation\n- `BLOCK_REQUEST` \u002F `BLOCK_SUBMIT`: Block operations\n- `STATUS_REQUEST` \u002F `STATS_REQUEST`: Node status\n\nDefault port: **20049**\n\n### Example Network Setup\n\n```bash\n# Terminal 1: Bootstrap CPU node\nquip-network-node cpu --port 20049 --auto-mine\n\n# Terminal 2: Join as CPU miner\nquip-network-node cpu --port 20050 --peer localhost:20049 --auto-mine\n\n# Terminal 3: Join as GPU miner (CUDA)\nquip-network-node gpu --port 20051 --peer localhost:20049 --auto-mine\n\n# Terminal 4: Join as GPU miner (Metal\u002FMPS on Mac)\nquip-network-node gpu --gpu-backend mps --port 20052 --peer localhost:20049 --auto-mine\n```\n\n### Network Simulator\n\nLaunch multiple nodes for testing:\n\n```bash\n# Mixed network (CPU + GPU)\nquip-network-simulator --scenario mixed\n\n# CPU-only network\nquip-network-simulator --scenario cpu --base-port 9000\n```\n\n## Security\n\n### QUIC Transport Security\n\nThe P2P network uses QUIC protocol which includes mandatory TLS 1.3 encryption:\n\n- **Built-in TLS 1.3**: All connections are encrypted by default\n- **Self-signed certificates**: Automatically generated for development\n- **TOFU (Trust On First Use)**: Peer certificates stored in `trust.db`\n\n### Production Certificates\n\nFor production deployments, configure custom certificates in TOML:\n\n```toml\n[global]\ntls_cert_file = \"\u002Fpath\u002Fto\u002Fcertificate.pem\"\ntls_key_file = \"\u002Fpath\u002Fto\u002Fprivate_key.pem\"\n```\n\n## Future Enhancements\n\n- Consensus mechanism for longest chain rule\n- Block validation and quantum proof verification\n- Persistent blockchain storage and peer list\n- Transaction validation and smart contracts\n- Multiple QPU support\n- Advanced difficulty algorithms\n- Real-time mining pool statistics\n- Client certificate authentication for enhanced security\n\n## License\n\nGNU Affero General Public License v3.0 - See LICENSE file for details\n","QuipNetwork\u002Fquip-protocol 是一个实验性的量子区块链网络节点项目，旨在通过量子退火技术实现工作量证明共识。其核心功能包括基于伊辛模型优化的量子退火PoW、支持多种矿工（量子处理器和经典模拟退火）之间的竞争挖矿、动态难度调整机制防止矿工垄断、连续获胜增加区块奖励等。此外，该项目还强调解决方案多样性以避免简单的挖矿攻击，并为每个矿工提供独特的ID及性能统计。尽管目前仅实现了量子PoW而未包含交易、账户等传统区块链特性，但其设计思路和技术探索适用于研究量子计算与区块链结合的可能性以及未来可能的应用场景。需要注意的是，此软件仅供实验演示使用，不建议用于生产环境。",2,"2026-06-11 03:48:15","high_star"]