SmartHoldem · نظام Web 4.0 البيئي
بلوكشين SmartHoldem: Web 4.0 وما بعد الكم الأمان
بنية تحتية متطورة لـ DPoS Blockchain
SmartHoldem هي طبقة الثقة اللامركزية والتسوية لـ Web 4.0. أُعيدت كتابتها من الصفر بلغة Rust، وتوفر بنية P2P مع اجتياز NAT مدمج ومقاومة كمومية.

مرّر المؤشر لرؤية العقد. من المنزل أو السيرفر. شبكة واحدة متكاملة.
السرعة والحجم
مبني للسرعة والحجم
يكسر النواة الجديدة لـ SmartHoldem المبنية على Rust حدود البلوك تشين التقليدية: فقد حلّت محرك محسّن وقاعدة بيانات Sled DB محل نقاط الاختناق في Node.js وPostgreSQL، مما يوفر مزامنة فائقة السرعة وإنتاجية عالية.
معالجة فورية للكتل
تُتحقق كتل تضم 500 معاملة وتُطبَّق في ~50 مللي ثانية. بفضل آلية BFT للنهائية والمعالجة المتوازية، تحقق الشبكة نهائية مطلقة وغير قابلة للعكس في فترة slot واحدة (~8 ثوانٍ).
قابلية توسع حقيقية بلا خوادم مركزية
مدعومة ببروتوكول Iroh P2P. لا حاجة لمزودي السحابة المركزيين، لكن يمكنك تشغيل عقدتك الخاصة. يمكن لأي جهاز كمبيوتر محمول أو Raspberry Pi أو جهاز محمول بمعالج ARM64 أن يكون عقدة تحقق كاملة خلف أي NAT دون الحاجة إلى عنوان IP ثابت.
صديق للبيئة وخفيف الوزن
تعمل عقدة التحقق الكاملة الآن بـ ~800 ميغابايت فقط من الذاكرة. يجعل DPoS مقترناً بتجريدات Rust عديمة التكلفة هذه الشبكة الأكثر كفاءة في استهلاك الطاقة على الإطلاق.

urovisiones
urovisiones الأداء
اختبارات التحميل الواقعية على النواة الجديدة المبنية بـ Rust تؤكد قابلية توسع على مستوى المؤسسات وبمستوى Visa.
الأداء مُقاس وليس مجرد ادعاء. تعكس المعايير التالية بنية Rust و Sled مع التحقق المتوازي من التوقيعات عبر Rayon وخطوط أنابيب تشفير محسّنة:
256
MultiPayments لكل TX
5.53B
عمليات / يوم (ذروة)
| التكوين | عمليات / ثانية | عمليات / ساعة | عمليات / يوم |
|---|---|---|---|
| 2000 TX/block (MultiPayments) | 64,000 | 230.4M | 5.53B |
| 1000 TX/block (MultiPayments) | 32,000 | 115.2M | 2.76B |
| 500 TX/block (MultiPayments) | 16,000 | 57.6M | 1.38B |
تحت الغطاء
الحزمة التقنية
محرك البلوك تشين الأساسي
- اللغة: 100% Rust مع التحقق المتوازي من التوقيعات (Rayon)، وأمان الذاكرة والتجريدات بدون تكلفة.
- قاعدة البيانات: مخزن المفاتيح والقيم المدمج Sled مع ضغط zstd = أكثر من 11.7M+ كتلة في حوالي ~8 GB، بديلاً عن تبعيات PostgreSQL القديمة.
- الإجماع: DPoS مع 21 مفوضاً نشطاً، معززاً بأداة نهائية BFT (نهائية حتمية في فترة زمنية واحدة).
- التشفير: نموذج أمان هجين. secp256k1 الكلاسيكي (BIP-Schnorr) + ما بعد الكم ML-DSA-44 (NIST FIPS 204) عبر Quantum Shield.
API وSDK وSmartNet
- جسر المطورين: واجهة IPC الأصلية window.smartholdem لتطبيقات Tauri dApps. وصول آمن ومعزول للتوقيع وتخزين P2P وحالة الشبكة.
- الكائنات القابلة للبرمجة: SmartObjects والرموز الأصلية. سجلات وإصدار بدون تكلفة عقود ذكية وبدون مخاطر EVM.
- تخزين البيانات: التحقق بعنونة محتوى BLAKE3. البيانات الوصفية مرسخة على السلسلة في SmartNetData، نزاهة مطلقة بدون فهارس خارجية.
- API و SDK: RESTful API متوافق بالكامل للخلف + SDK. تدفقات دفع QUIC في الوقت الفعلي لتحديثات فورية بدون استطلاع.
بروتوكول نقل P2P لـ Web 4.0
- البروتوكول: مبني على Iroh (QUIC/UDP)، يوفر اتصالات مشفرة ومتعددة القنوات مع اجتياز NAT الأصلي وثقب الاتصال. يمكن للعقد إنتاج الكتل ومزامنتها من وراء أجهزة توجيه منزلية بدون عنوان IP ثابت.
- طبولوجيا الشبكة: بنية مزدوجة المكدس. تجري الاتصالات الأساسية عبر شبكة Iroh اللامركزية، بينما يتم الحفاظ على جسر WebSocket/Protobuf القديم (port 4001) حصراً للتوافق مع الإصدارات السابقة للعقد على الخوادم.
- الاكتشاف اللامركزي: يعتمد اكتشاف النظراء على Mainline DHT وmDNS المحلي وكتاب عناوين النظراء الموقَّع تشفيرياً، مما يزيل أي اعتماد على DNS المركزي أو خدمات الترحيل العام.
اللامركزية الحقيقية
تُدار من المجتمع، لا من الشركات
اللامركزية أساسية. بلوكشين SmartHoldem DPoS غير قابلة للتغيير، جميع العمليات لا رجعة فيها. أي معاملة متاحة بشفافية للعرض على مستكشف الكتل أو عبر API في أي وقت.
تصويت ديمقراطي
يتم اختيار المُ核实者 بناءً على السمعة، وليس التحكم المركزي.
لا عملات مجمدة
يصوّت المستخدمون بقوة رصيدهم. العملات تظل تحت سيطرة المستخدم الكاملة.
المساءلة
أي حامل لـ STH يمكنه التصويت، انتخاب، أو إلغاء المشرفين. المشرفون غير الفعّائسين يُستبدلون بسرعة من قبل المجتمع.
ملكية
الاحتفاظ بأكثر من STH واحد يمنح حقوق تصويت كاملة على الشبكة.


نظام المشرفين
TOP 21: حماية الشبكة
المندوبون (المعروفون أيضاً بالشهود أو منتجي الكتل) مسؤولون عن التحقق من المعاملات وإنشاء كتل جديدة وحماية شبكة SmartHoldem. لا يمكنهم تعديل بيانات المعاملات أو التأثير فيها.
21
المشرفون النشطون في TOP
8s
متوسط زمن الكتلة
100%
تصويت المجتمع
0%
تحكم مركزي
نظام الإشراف تنافسي للغاية. يمكن للمشرف الانتقال إلى أو من TOP 21 في أي وقت. هذا المخطط المستدام يوفر فرصة للمشرفين الجدد لإثبات أنفسهم و thu hút اهتمام المجتمع.
الاقتصاد
مكافآت مستدامة. انبعاث بدون تضخم.
لا يوجد لا انبعاث في بلوكشين SmartHoldem (DPoS). يتلقى المشرفون المكافآت حصرياً من رسوم المعاملات، مما يضمن نموذج اقتصادي تناقصي ومستدام.
المشرف الذي يوقّع الكتلة يتلقى جميع رسوم الشبكة للمعاملات المشمولة في تلك الكتلة.
كيف يكسب المشرفون
500 STH
لكل كتلة (حد أقصى)
500 معاملة قياسية في كتلة → ما يصل إلى 500 STH مكتسبة.
10,000 STH
رسوم التسجيل
معاملة تسجيل مشرف → 10,000 STH مكتسبة.
500 STH
إصدار توكن
يتم حرق 50% من الرسوم
يحصل المندوب على مكافأة عند كل إطلاق لتوكن Web4 أصيل جديد.
أنواع المعاملات المتقدمة
يدعم SmartHoldem نظاماً غنياً بأنواع المعاملات، مما يحقق إيرادات رسوم متنوعة:
شارك
كن مشرفاً في SmartHoldem
تأمين الشبكة لم يعد حكراً على مراكز البيانات المؤسسية. بفضل نواة Rust الجديدة وبروتوكول نقل Iroh P2P، يمكن لأي شخص تشغيل عقدة تحقق والمشاركة في الإجماع من أي مكان في العالم.
المواصفات الموصى بها للعقدة
8 غيغابايت RAM، 4 أنوية معالج، 64 غيغابايت HDD أو 32 غيغابايت SSD.
- 1
سجّل وانضم إلى المنافسة
تأمين الشبكة لم يعد حكراً على مراكز البيانات المؤسسية. بفضل نواة Rust الجديدة وبروتوكول نقل Iroh P2P، يمكن لأي شخص تشغيل عقدة تحقق والمشاركة في الإجماع من أي مكان في العالم.
- 2
إعداد عقدتك (دون الحاجة إلى IP ثابت)
قم بتنزيل الملف الثنائي الخفيف sth-core-pq. يعمل بـ ~800 ميغابايت فقط من الذاكرة و~8 غيغابايت من مساحة القرص. بفضل تقنية Iroh QUIC NAT traversal، لا تحتاج إلى عنوان IP ثابت أو منافذ مفتوحة — أنتج الكتل بأمان من جهازك المحمول أو Raspberry Pi أو سيرفرك.
- 3
أعلن عن ترشحك كمندوب
قدّم مقترحاً في منتدى المجتمع يتضمن تفاصيل تكوين شبكتك، ونسبة العائد المقترحة، والخدمات الإضافية. ثم قدّم مندوبك للمجتمع عبر Telegram واحرص على التواصل الفعّال.
- 4
احصل على عائد حقيقي
احصل على 100% من رسوم الشبكة الناتجة عن الكتل التي تنتجها. مع غياب الإصدار التضخمي تماماً، تستند مكافآتك إلى فائدة شبكية حقيقية: التحويلات، وإطلاق التوكنات، وتسجيل الأسماء، والتخزين P2P، وتمرير dVPN، وغيرها.
- 5
تفاعل وانمِ المنظومة
يختار المجتمع المندوبين. ابنِ الثقة من خلال تقديم مشاركة شفافة في المكافآت، وتشغيل بذور Netfory العامة، أو المساهمة الفعّالة في منظومة Web 4.0.

المجتمع
التواصل المجتمعي
كمشرف، المشاركة النشطة والتواصل مع المجتمع حيوية للحصول على الأصوات. توليد أماكن المشرفين تنافسي ويحتاج أكثر من إدارة العقد.
بناء تطبيقات جديدة مبنية على SmartHoldem
تقديم مراجعات الكود والإبلاغ عن الثغرات
التواصل المجتمعي والتعليم
تقديم نسبة من المكافآت للمصوّتين (للوصول إلى TOP 21)
يتم قياس المكافأة بناءً على حصة مشاركة المصوّت ونسبة دفع المشرف.
الدرع الكمي
الدرع الكمي لـ SmartHoldem
كيف نحمي البلوكشين من الحواسيب المستقبلية
بينما يتابع السوق الرسوم البيانية، تتنامى تهديدات قادرة على إبطال التشفير الكلاسيكي. يمكن لخوارزمية Shor على حاسوب كمّي بالغ القوة أن تكسر ECDSA — الأساس الرياضي لمعظم سلاسل الكتل اليوم. لا تنتظر SmartHoldem يوم X الافتراضي.
نبني الدرع اليوم. المرحلة أ (التعهدات بالمفاتيح ما بعد الكمية) نشطة بالفعل في الشبكة الرئيسية.

خارطة الطريق
خطة التنفيذ: النموذج الهجين
نستبعد التحولات المفاجئة عبر الهارد فورك والهجرات الجماعية المفروضة. الانتقال نحو المرونة الكمية تدريجي وسلس وقابل للتوافق مع الإصدارات السابقة:
المرحلة 1
التعهدات بالمفاتيح (نشطة)
- يمكن للمستخدمين بالفعل تثبيت تجزئة SHA-256 لمفتاحهم العام المستقبلي ML-DSA-44 عبر vendorField (sthpq1:...).
- يمنع هذا هجمات 'حالة التسابق' عند تفعيل المرحلة 2، مما يؤمّن المحفظة قبل أن يتجسّد التهديد الكمّي.
المرحلة 2
التوقيعات الثانية الهجينة (مقبولة)
- يمكن للمستخدمين تسجيل مفتاح عام ما بعد كمّي ML-DSA-44 (NIST FIPS 204) كتوقيع ثانٍ على محفظتهم الحالية.
- من تلك اللحظة، تستلزم كل معاملة توقيعَين: التوقيع الكلاسيكي secp256k1 والتوقيع الجديد المقاوم للحوسبة الكمية.
- يبقى المفتاح الكلاسيكي نشطاً لضمان التوافق الكامل، فيما يضيف المفتاح ما بعد الكمّي طبقة ثانية مقاومة للحوسبة الكمية — مشكّلاً بذلك نظام تشفير هجيناً متيناً يحمي أصولك حتى في حال اختراق أي من الخوارزميتين.
المرحلة 3
المرونة الكاملة للشبكة (مخطط لها)
- يوقّع جميع المندوبين الـ 21 النشطين على الكتل بتوقيعات ما بعد كمية لمنع انتحال التوافق.
- تستخدم طبقة نقل Iroh P2P تبادلاً هجيناً للمفاتيح (X25519 + ML-KEM-768) لتأمين بيانات المراسلة والتطبيقات اللامركزية (SHIP-40).
البنية المعمارية
طوّر القفل لا الخزنة
خلافاً للشبكات الأخرى التي تُلزم المستخدمين بإنشاء محافظ جديدة ونقل الأصول جماعياً، تستثمر SmartHoldem بنيتها الفريدة للتوقيع الثاني من أجل ترقية كمية سلسة.
تشكيل العنوان
عنوان SmartHoldem الخاص بك مشتق من مفتاحك العام الكلاسيكي secp256k1. يبقى هذا دون تغيير.
تفعيل المفتاح الثاني
تُسجّل مفتاحك العام ما بعد الكمّي ML-DSA-44 كتوقيع ثانٍ على عنوانك الحالي.
الحماية الهجينة
تستلزم كل معاملة الآن كلا التوقيعَين — الكلاسيكي وما بعد الكمّي — لتكون صالحة.
النتيجة
- لا حاجة لتغيير محفظتك أو عنوانك
- تبقى عملاتك في مكانها تماماً كما كانت لسنوات
- لا هجرات معقدة للمحافظ
- حسابك محمي الآن بطبقة تشفير مزدوجة
- حتى لو تمكن حاسوب كمي من اشتقاق مفتاحك الخاص الأول، فلن يستطيع تحريك أموالك دون التوقيع الثاني الصالح (المقاوم للحوسبة الكمية)
للمستخدمين بتوقيع واحد: يمكنك تفعيل التوقيع الثاني في أي وقت لتمكين الحماية الكمية فورًا، أو الانتقال إلى أنواع عناوين جديدة آمنة كميًا في المستقبل البعيد.
التقنية العميقة
التفاصيل التقنية وحماية الشبكة
المشرفون تحت الحماية
- في شبكة DPoS، يوقّع المشرفون الكتل
- إن تعرّضت توقيعات المندوبين للاختراق، فإن ذلك يهدد سلامة البلوكتشين بأكمله
- تنفيذ PQC على مستوى البروتوكول يجعل SmartHoldem "قلعة رقمية" مقاومة لتزوير الإجماع
حجم توقيع مُحسَّن
- اخترنا ML-DSA-44 (NIST FIPS 204) لتوازنه المثالي: توقيعات بحجم ~2.4 كيلوبايت وتحقق أسرع من الميلي ثانية
- تضمن المعالجة المتوازية في نواة Rust (Rayon) التحقق الفوري من هذه المعاملات الثقيلة دون فقدان سرعة المزامنة
المرونة الخوارزمية
- يتضمن البروتوكول بايت alg_id في كائنات PQC
- يتيح ذلك ترقيات مستقبلية سلسة (مثل الانتقال إلى FN-DSA-512 / Falcon) دون الحاجة إلى تغيير العناوين أو ترحيل الأموال
- بالنسبة للمستخدم، يبدو هذا كمحفظة مألوفة تمامًا
التطوير
الكود قيد الإنشاء
تتضمن نواة Rust (sth-core-pq) بالفعل الأساس التشفيري لطبقة التحقق الجديدة. إليك لمحة عن التكامل الهجين:
//! Quantum Shield: ML-DSA-44 (NIST FIPS 204) keys derived from a passphrase, plus the stage-A
//! commitment format (`sthpq1:<alg>:<sha256(pk)>` in a self-transfer vendorField). See docs/SPEC-PQ-V3.md.
use crate::error::{Error, Result};
use ml_dsa::{EncodedSignature, EncodedVerifyingKey, MlDsa44, Signature, SigningKey, VerifyingKey, B32};
use sha2::{Digest, Sha256};
/// Algorithm ids (first byte of every PQ object).
pub const ALG_ML_DSA_44: u8 = 0x01;
pub const PK_LEN: usize = 1312;
pub const SIG_LEN: usize = 2420;
/// Domain separation for the ML-DSA context string.
const CTX: &[u8] = b"sth-pq-v1";
/// Context of stage-C block signatures (`M_B = sha256(header || blockSignature)`).
pub const BLOCK_CTX: &[u8] = b"sth-pq-block-v1";
/// Commitment prefix in vendorField.
pub const COMMITMENT_PREFIX: &str = "sthpq1:";
pub struct PqKeyPair {
signing: SigningKey<MlDsa44>,
}
impl PqKeyPair {
/// Deterministic: seed ξ = sha256("sth-pq-v1" || passphrase). Same passphrase → same key on every device.
pub fn from_passphrase(passphrase: &str) -> Self {
let mut h = Sha256::new();
h.update(CTX);
h.update(passphrase.as_bytes());
let seed: [u8; 32] = h.finalize().into();
Self::from_seed(&seed)
}
pub fn from_seed(seed: &[u8; 32]) -> Self {
Self { signing: SigningKey::<MlDsa44>::from_seed(&B32::from(*seed)) }
}
/// FIPS 204 pkEncode — 1 312 bytes.
pub fn public_key(&self) -> Vec<u8> {
self.signing.expanded_key().verifying_key().encode().to_vec()
}
pub fn public_key_hex(&self) -> String {
hex::encode(self.public_key())
}
/// Deterministic ML-DSA-44 signature (2 420 bytes) over `message` with the sth context.
pub fn sign(&self, message: &[u8]) -> Result<Vec<u8>> {
self.sign_with_ctx(message, CTX)
}
pub fn sign_with_ctx(&self, message: &[u8], ctx: &[u8]) -> Result<Vec<u8>> {
let sig = self.signing.expanded_key().sign_deterministic(message, ctx).map_err(|_| Error::Serialization("ml-dsa sign".into()))?;
Ok(sig.encode().to_vec())
}
/// What a wallet publishes in stage A: `sthpq1:01:<sha256(pk) hex>`.
pub fn commitment(&self) -> String {
commitment_for_public_key(&self.public_key())
}
}
pub fn commitment_hash(public_key: &[u8]) -> [u8; 32] {
Sha256::digest(public_key).into()
}
pub fn commitment_for_public_key(public_key: &[u8]) -> String {
format!("{COMMITMENT_PREFIX}{:02x}:{}", ALG_ML_DSA_44, hex::encode(commitment_hash(public_key)))
}
pub fn verify(public_key: &[u8], message: &[u8], signature: &[u8]) -> Result<bool> {
verify_with_ctx(public_key, message, signature, CTX)
}
pub fn verify_with_ctx(public_key: &[u8], message: &[u8], signature: &[u8], ctx: &[u8]) -> Result<bool> {
if public_key.len() != PK_LEN || signature.len() != SIG_LEN {
return Ok(false);
}
let pk = EncodedVerifyingKey::<MlDsa44>::try_from(public_key).map_err(|_| Error::Serialization("ml-dsa pk".into()))?;
let sig = EncodedSignature::<MlDsa44>::try_from(signature).map_err(|_| Error::Serialization("ml-dsa sig".into()))?;
let Some(sig) = Signature::<MlDsa44>::decode(&sig) else { return Ok(false) };
Ok(VerifyingKey::<MlDsa44>::decode(&pk).verify_with_context(message, ctx, &sig))
}
/// Stage B: PQ public key registered by a wallet (type 1, v3). Lives in `WalletState.pq_key`, so undo is automatic.
#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct PqKey {
pub algorithm: u8,
/// Raw PQ public key, hex (1 312 bytes for ML-DSA-44).
pub public_key: String,
pub since: u64,
}
/// Parsed stage-A commitment.
#[derive(Debug, Clone, PartialEq, Eq, serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct PqCommitment {
pub algorithm: u8,
/// sha256(public key), hex.
pub commitment: String,
pub height: u64,
}
/// `sthpq1:<alg 2 hex>:<64 hex>` → (alg, hash hex). Only known algorithm ids are accepted.
pub fn parse_commitment(vendor_field: &str) -> Option<(u8, String)> {
let rest = vendor_field.strip_prefix(COMMITMENT_PREFIX)?;
let (alg, hash) = rest.split_once(':')?;
if alg.len() != 2 || hash.len() != 64 || !hash.bytes().all(|b| b.is_ascii_hexdigit() && !b.is_ascii_uppercase()) {
return None;
}
let alg = u8::from_str_radix(alg, 16).ok()?;
(alg == ALG_ML_DSA_44).then(|| (alg, hash.to_string()))
}التفوق الكمي ليس نهاية علم التشفير، بل مرحلته التطورية التالية. نحن نختار رياضيات لا يمكن 'حلّها' بالقوة الغاشمة وندمجها مباشرةً في صميم شبكة Web 4.0 DPoS الخاصة بنا. المستقبل موجود بالفعل. وهو محمي. المستقبل هنا بالفعل. وهو محمي.
انضم إلى الشبكة
عقدتك. قواعدك. Web 4.0 الخاص بك.
يمكنك تأمين الشبكة بطرق عديدة: إنتاج الكتل كمندوب، أو بذر التطبيقات اللامركزية كمشغّل Netfory، أو تشغيل مرحّل dVPN، أو الاحتفاظ بالعملة والتصويت فحسب. لا تضخم، ومكافآت نفعية حقيقية، وأساس مقاوم للحوسبة الكمية مبني بـ Rust. الإنترنت اللامركزي يحتاج إلى بُناة — ويبدأ بك أنت.

