Bitcoin Forum
July 01, 2026, 03:55:36 PM *
News: Latest Bitcoin Core release: 31.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: [ANN] YonaCode : A New PoW Layer-1 Solving 51% Attacks & State Bloat with Dual R  (Read 16 times)
duyvn878 (OP)
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
Today at 02:36:09 AM
Last edit: Today at 02:48:51 AM by duyvn878
 #1

🌐 Website: yonacode.com
💻 Open-source (GitHub): https://github.com/duyvn878-ui/YonaCode
YonaCode Go (Academic codename: YonaCode Minimalist) is a completely original Layer-1 Proof-of-Work (PoW) blockchain platform built entirely from scratch. Powered by a multi-process parallel architecture (Go and Rust), the project focuses on aggressively solving three core problems of legacy blockchains: Finality vulnerabilities (51% attacks), State Bloat (Storage DoS), and transaction latency in the pure account model (Nonce Gap).
Below is a detailed breakdown of YonaCode's technical breakthroughs:
1. VNT Consensus: Mathematical Finality & Segmented Governance
YonaCode eliminates absolute reliance on the traditional "Longest Chain Rule" of Nakamoto Consensus, introducing a 2-zone Ledger governance structure instead:
5-Block Finality Firewall (Micro-protection): The ledger is divided into 2 zones: the Flexible Zone (the 5 latest blocks to resolve micro-forks caused by network latency) and the Boulder Zone (from the 6th block backwards). When a block reaches an N-5 depth (approximately 6 minutes with a 75s block time), the Rust Core mathematically locks its state as Permission to change: DISABLED. Any Deep Reorg attempts (51% attacks) aimed at rewriting finalized history are immediately rejected at the network layer, regardless of the attacker's Hashrate dominance.
"Invisible Hand" Protocol (Macro-physical incident handling): In the event of "Black Swan" disasters causing a global Internet Network Partitioning, instead of letting the algorithm blindly wipe out thousands of blocks from the weaker branch (causing massive asset loss), VNT Consensus allows the network to temporarily split into 2 parallel chains. Restoring global consistency relies not on forced code execution, but on market dynamics—driven by transaction volume and market valuation (the Invisible Hand).
Static Peer & Sync Target Hash: To support this, the Network Manager (Go) provides strict network modes: Anchor Mode, Block Trust Mode, and Strict Isolation Mode, allowing Nodes to safely survive Eclipse attacks. Users can specify syncing by Target Hash (O(1) step back) instead of manually rolling back a specific number of blocks.
📌 Author's Note regarding the "Invisible Hand" rule: I am aware that allowing a temporary chain split instead of automatic branch deletion may spark debate. I highly recommend reading the Whitepaper to fully understand the rationale behind this design, as detailed explanations are provided there. Alternatively, feel free to leave a comment below—I will be happy to discuss and answer your questions!
2. Ultra-Light Architecture: "Great Purge 48H" Protocol & JMT
To maintain true decentralization without forcing Node operators to buy massive terabyte-sized drives, YonaCode implements a progressive I/O optimization strategy:
Epoch-based Batch Purge: Every 24 hours (1,152 blocks) constitutes an Epoch. As soon as block 2,304 is mined (when Epoch 1 is 48 hours deep), the Node executes an Atomic delete command on RocksDB, permanently and instantly freeing up all obsolete Transaction Bodies from those 1,152 blocks.
Mathematical History Verification: Despite deleting bulky transaction data, Nodes permanently retain Block Headers (containing the State Root & PoW Hash). Combined with the Jellyfish Merkle Tree (JMT)—a Sparse Merkle Tree (SMT) structure that stores versioning—Nodes can cryptographically verify the integrity of any wallet balance without needing to store old transaction logs.
State Bloat Protection: Ditching UTXO, YonaCode uses a Pure Account Model. The wallet state is a single record (Balance, Nonce). The fee for creating a new account is hardcoded at 1,000 VNT to economically prevent State spam/dust attacks.
3. Vanguard Network Protocol & Verification Engine Separation (Rust/Go)
YonaCode completely isolates the Network layer from the Consensus layer to optimize security via a "Paranoid Defense" architecture:
P2P Layer (Go-Libp2p): Manages the Kademlia DHT, GossipSub, and Hole Punching (DCUtR/AutoNAT). Every incoming block must pass through the Outer Guard Layer to verify Payload Size, the MTP-11 Time Firewall (preventing Time-Warp attacks from manipulating difficulty), and the validity of the PoW hash before being passed to the consensus engine.
Consensus Core (Rust): Receives data via gRPC and executes Parallel Signature Verification using the Rayon library (maximizing CPU multi-threading). The Rust Core automatically rebuilds the JMT from raw transactions (Deterministic Dry-run) and compares the StateRoot to finalize validity. Even a 1 VNT discrepancy in the accounting equation (∑Deducted = ∑Credited + Fees) will result in immediate block destruction.
4. Custom Blake3-PoW Algorithm & ASIC Resistance
To prevent legacy ASIC farms from dominating the network, YonaCode utilizes Context String Hashing (YonaCode Minimalist PoW v1.0). All current ASIC rigs designed for pure Blake3 will return invalid hashes, instantly rendering them useless on this chain.
Furthermore, the LWMA (Linear Weighted Moving Average) algorithm continuously calculates the real-time generation of preceding blocks to smoothly adjust the Target, ensuring a stable Block time of 75 seconds.
5. EBP Protocol (Exchange Batch Protocol) & TXSQ Format
This is a custom Layer-1 design explicitly built to solve the Nonce Gap / Out-of-Order nightmare for centralized Exchanges:
When an Exchange broadcasts tens of thousands of withdrawal orders simultaneously, traditional P2P latency often causes Nonce 105 to arrive before Nonce 104, leading to Mempool rejection (Stall/Reject).
YonaCode EBP: Packages thousands of transactions into a single TXSQ binary payload (Exchange Batch Protocol). The Mempool automatically tracks the cumulative Current Nonce + Index, verifies signatures in parallel via Ed25519, and unpacks them sequentially to guarantee Atomic execution. This provides ultra-high throughput for institutional operations.
Conclusion
To be absolutely clear: YonaCode Go ($YGO) is a 100% original, independently developed Layer-1 built entirely from the ground up. It is NOT a source code fork of any existing project, nor is it a typical memecoin.
Backed by the VNT Consensus, the dual-process Rust/Go architecture, the Great Purge 48H, and the EBP protocol, this is a hardcore technical systems blockchain engineered to permanently solve storage DoS and secure deep protocol immutability.
The project is currently in its Bootstrap phase. Developers, cryptographers, and system engineers (Node Runners/Miners) interested in contributing hash power or auditing our open-source codebase can access the repository directly on GitHub.
Full technical details are available in Whitepaper V1.0 on the Website: yonacode.com
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!