أهم الأساسيات التشفيرية وراء كل بلوكتشين

أي ادعاء في البلوكتشين — مثل «هذه المعاملة نهائية»، أو «هذا العنوان يملك هذا الأصل»، أو «هذا السجل التاريخي لم يُعدَّل» — يرجع في النهاية إلى عدد محدود من الأساسيات التشفيرية، لكلٍ منها مهمة ضيقة ومحددة. ولا واحدة منها اختراعٌ للبلوكتشين؛ فدوال التجزئة والتوقيعات الرقمية وأشجار Merkle سبقت Bitcoin بعقود. ما فعلته البلوكتشينات هو جمعها في نظام لا يحتاج فيه أي ادعاء من هذه الادعاءات إلى الثقة في طرف واحد كي يظل صحيحًا.

يشرح هذا الدليل الأساسيات التي تتحمل العبء فعلًا: دوال التجزئة التي تمنح البيانات بصمة، والتوقيعات الرقمية التي تُجيز المعاملات، وأشجار Merkle التي تجعل مجموعات البيانات الضخمة قابلة للتحقق منها على أجزاء، ورياضيات المنحنيات الإهليلجية التي تعمل عليها تلك التوقيعات، ومخططات الالتزام — اللبنة التي تقود إلى إثباتات المعرفة الصفرية. وفهم كل واحدة منها هو أسرع طريق لفهم ما الذي يفعله البلوكتشين فعلًا تحت الغطاء.

دوال التجزئة التشفيرية (SHA-256 وKeccak)

تأخذ دالة التجزئة مُدخلًا بأي حجم وتنتج بصورة حتمية مخرجًا ثابت الحجم — «ملخصًا» — بحيث إن قلب بت واحد في المُدخل يبعثر المخرج بالكامل، ويصبح العثور على مُدخلين مختلفين لهما المخرج نفسه غير ممكن عمليًا من الناحية الحسابية. وهذه الخاصية، أي مقاومة التصادم، هي ما يجعل التجزئة بصمة مدمجة تكشف العبث لبيانات كبيرة بأي حجم.

يستخدم Bitcoin ‏SHA-256 في كل أجزائه: تُربط رؤوس الكتل بإدراج تجزئة SHA256(SHA256()) لرأس الكتلة السابقة في كل رأس جديد، وبالتالي فإن تعديل أي كتلة قديمة يغيّر تجزئتها ويكسر كل الرؤوس اللاحقة لها (Bitcoin Developer Guide). ويُستخدم البناء نفسه، أي double-SHA-256، لتجزئة المعاملات داخل شجرة Merkle الخاصة بالكتلة (مرجع Bitcoin.org).

أما Ethereum فيعتمد Keccak-256 (نسخة Keccak الأصلية، وهي مختلفة عن معيار NIST SHA-3 اللاحق) كدالة التجزئة العامة. ويُشتق كل عنوان حساب من آخر 20 بايت من تجزئة Keccak-256 الخاصة بـالمفتاح العام للحساب (ethereum.org)، كما تدعم الدالة نفسها عنونة المحتوى بأسلوب المفتاح/القيمة في Merkle Patricia Trie التي تخزن حالة Ethereum.

والتجزئة كمان هي اللي بتربط رؤوس الكتل في سلسلة بدل ما تفضل مجرد مجموعة سجلات منفصلة: تغيير أي رأس بيغيّر تجزئته وبيكسر الإشارات الموجودة في الرؤوس اللاحقة. أما شرط إعادة تنفيذ العمل اللاحق واللحاق بالشبكة الصادقة فهو خاص بإجماع إثبات العمل في Bitcoin؛ فلو مهاجم غيّر كتلة قديمة، لازم يعيد إثبات العمل الخاص بالكتلة دي وكل العمل اللي بعدها، ثم يلحق بالسلسلة الصادقة (ورقة Bitcoin البيضاء، القسم 4). سلاسل البلوكتشين التانية بتتحقق من صحة التاريخ وبتعتبره نهائيًا وفق قواعد إجماع مختلفة، ولذلك ربط التجزئات لوحده ما بيخلقش تكلفة إثبات العمل دي. وترابط تجزئات الرؤوس هو حرفيًا سبب تسمية بنية البيانات blockchain.

تشفير المفتاح العام والتوقيعات الرقمية (ECDSA وEdDSA وBLS)

لا تملك البلوكتشين شاشة تسجيل دخول، لذا تحتاج إلى طريقة أخرى لإثبات أن «هذه المعاملة صدرت بالفعل من مالك هذا الحساب». ويحل تشفير المفتاح العام ذلك عبر زوج مفاتيح: مفتاح خاص يبقى سريًا، ومفتاح عام يمكن مشاركته بحرية. ينتج عن توقيع معاملة بالمفتاح الخاص توقيع رقمي يستطيع أي شخص التحقق منه باستخدام المفتاح العام؛ وبذلك يثبت التفويض من دون كشف المفتاح الخاص نفسه.

تشتق حسابات Ethereum مفتاحها العام من المفتاح الخاص باستخدام خوارزمية التوقيع الرقمي بالمنحنى الإهليلجي، ECDSA، فوق المنحنى secp256k1 — وهو المنحنى نفسه الذي يستخدمه Bitcoin (وثائق حسابات ethereum.org; EIP-2 وإصلاح قابلية تطويع توقيع secp256k1). التحقق من ECDSA سريع وقد خضع لعقود من التدقيق، لكنه يحمل نقطة ضعف تشغيلية مهمة للتصاميم الأحدث: توقيعات ECDSA الفردية لا تتجمع بكفاءة، لذا فإن التحقق من آلاف منها يعني إجراء آلاف عمليات الفحص المنفصلة.

وهذه هي الفجوة التي تملؤها توقيعات EdDSA وBLS. تستخدم EdDSA (في سلاسل مثل Solana وStellar) بناءً مختلفًا للمنحنيات، وهو حتمي ومقاوم لبعض مشكلات التنفيذ التي سببت تاريخيًا أخطاء إعادة استخدام nonce في ECDSA. أما توقيعات BLS فتذهب أبعد: بفضل خاصية الاقتران الرياضية في المنحنيات التي تستخدمها، يمكن جمع كثير من توقيعات BLS في توقيع مُجمَّع واحد يتحقق منها كلها دفعة واحدة. وتعتمد طبقة توافق إثبات الحصة في Ethereum على ذلك تحديدًا؛ إذ يوقّع المُصدِّقون attestations بمفاتيح BLS حتى تتمكن beacon chain من جمع أصوات مئات الآلاف من المُصدِّقين في توقيعات مدمجة يمكن التحقق منها بسرعة، وهو ما يجعل إثبات الحصة واسع النطاق عمليًا أصلًا (ethereum.org، The Beacon Chain). كما تتيح Ethereum عمليات المنحنى BLS12-381 كتعليمات EVM مسبقة التجهيز، دعمًا للتحقق من توقيعات BLS في العقود الذكية (EIP-2537).

أشجار Merkle

تسمح شجرة Merkle للبلوكتشين بتلخيص آلاف المعاملات في تجزئة واحدة من 32 بايت، من دون إجبار كل مشارك على تخزين كل معاملة. الأوراق هي تجزئات عناصر البيانات الفردية (المعاملات وحالات الحسابات)، ويجري وصل كل زوج من التجزئات ثم تجزئته مرة أخرى، وتتكرر العملية حتى تبقى تجزئة واحدة — الجذر (Bitcoin Developer Guide). ويُخزَّن هذا الجذر مباشرة في رأس الكتلة، وهو ما يتيح للعقدة الكاملة الالتزام بمحتوى كتلة كامل بمساحة إضافية شبه معدومة.

والفائدة هي حجم الإثبات. فلكي تثبت أن معاملة واحدة موجودة في كتلة، لا تحتاج إلى الكتلة كلها؛ يكفي المعاملة مع «فرع Merkle»، أي تجزئات الأشقاء على المسار من تلك الورقة إلى الجذر، ويكون عددها عادة في حدود log₂(n) من التجزئات إذا كان عدد المعاملات n. وهذا هو أساس التحقق المبسط من المدفوعات (SPV): إذ يستطيع عميل خفيف لا يملك سوى رؤوس الكتل أن يتحقق من حدوث معاملة بعينها بمراجعة فرع Merkle مقابل جذر الرأس، من دون تنزيل البلوكتشين كاملًا (Bitcoin Developer Guide).

توسع Ethereum الفكرة عبر Merkle Patricia Trie، وهو مزيج من شجرة Merkle وtrie بادئات (radix) يُستخدم لتخزين حالة الحسابات كاملة، لا مجرد قائمة معاملات. ويحمل كل رأس كتلة ثلاثة جذور trie منفصلة — stateRoot وtransactionsRoot وreceiptsRoot — ويمكن إثبات كل منها على نحو مستقل (ethereum.org). وهذا ما يتيح لعقد ذكي أو عميل خفيف أن يتحقق من رصيد حساب واحد أو خانة تخزين واحدة من دون إعادة تشغيل السلسلة كلها.

تشفير المنحنيات الإهليلجية

تشفير المنحنيات الإهليلجية (ECC) هو الأساس الرياضي الذي تقوم عليه جميعًا ECDSA وEdDSA وBLS. فبدل الاعتماد على صعوبة تحليل الأعداد الكبيرة إلى عوامل (كما يفعل RSA التقليدي)، يعتمد ECC على صعوبة مسألة اللوغاريتم المنفصل للمنحنيات الإهليلجية: إذا أُعطيت نقطة على المنحنى وصلنا إليها بإضافة نقطة أساس إلى نفسها مرات كثيرة، فمن غير الممكن حسابيًا معرفة عدد مرات الإضافة، رغم أن حساب النقطة نفسها إلى الأمام سهل. وهذا التفاوت — سهل في اتجاه وصعب عكسه — هو بالضبط ما يجعل استعمال المفتاح الخاص للتوقيع آمنًا، بينما يبقى نشر المفتاح العام المشتق منه آمنًا.

المنحنى ومخطط التوقيع المحددان بيفرقوا. بيستخدم كل من Bitcoin وEthereum المنحنى secp256k1، وهو منحنى Koblitz وحّدته Standards for Efficient Cryptography Group بمعلمات 256-بت مدروسة جيدًا (SEC 2: Recommended Elliptic Curve Domain Parameters). منظومات تانية بتختار مقايضات مختلفة: Ed25519 هو مخطط توقيع EdDSA محدد مبني على منحنى Edwards25519 (RFC 8032، القسم 5.1)، وRFC 8032 بيضعه عند مستوى أمان تقليدي يقارب 128 بت (القسم 8.5). أما BLS12-381 فهو منحنى ملائم لعمليات الاقتران، واختير لعمليات زي تجميع توقيعات BLS، ويصف EIP-2537 مستوى أمان يزيد على 120 بت (EIP-2537). التقديرات دي مش معناها إن الأنظمة بتقدم «الأمان نفسه لكل بت في المفتاح»؛ فهي بتستخدم مجموعات وترميزات وافتراضات مختلفة، وطول المفتاح الاسمي مش هو قوة الأمان في حد ذاته. مثلًا، NIST بيربط مستوى الأمان التقليدي البالغ 128 بت بمفاتيح ECC عادية طولها 256–383 بت، لكن بمفاتيح RSA طولها 3072 بت (NIST SP 800-57 Part 1 Rev. 5، الجدول 2)، وده بيساعد في تفسير ليه أنظمة المنحنيات الإهليلجية أصبحت الاختيار الافتراضي لحسابات البلوكتشين.

مخططات الالتزام (جسر إلى المعرفة الصفرية)

يتيح لك مخطط الالتزام أن «تُثبِّت» قيمة — أي تنشر شيئًا يربطك بقطعة بيانات محددة — من دون كشف البيانات نفسها، ثم «تفتح» الالتزام لاحقًا لتثبت ماهيتها. وتشبيهه اليومي ظرف مختوم: يمكنك أن تعطي شخصًا ظرفًا مختومًا اليوم لإثبات أنك حسمت إجابة بالفعل، من دون أن يراها حتى تختار فتح الظرف لاحقًا، وبعد ختمه لا يمكنك تبديل الإجابة بداخله.

قد يبدو ده أساسًا بسيطًا، لكنه الجزء الحامل لمعظم أنظمة إثبات المعرفة الصفرية. فتصميم Ethereum لإتاحة البيانات المعتمد على blobs، مثلًا، بيستخدم التزامات KZG متعددة الحدود لاختزال كل blob إلى التزام تشفيري صغير. يقدر إثبات KZG يوثّق تقييمًا أو خلية مأخوذة كعينة مقابل الالتزام ده، لكنه لوحده ما يثبتش إن الـ blob كامل متاح: الإتاحة بتيجي من قواعد التوزيع وأخذ العينات في طبقة الإجماع، بينما KZG بيوفر فحص سلامة البيانات اللي تم استلامها (EIP-4844؛ EIP-7594، ‏PeerDAS). الفصل ده هو اللي بيسمح للمُتحقق يفحص جزءًا صغيرًا من blob من غير ما يخلط بين إثبات تقييم مدمج وبين دليل على إن كل بيانات الـ blob اتنشرت. وجذر Merkle نفسه، في الحقيقة، مخطط التزام بسيط: فهو يلتزم بمجموعة بيانات كاملة عبر تجزئة جذره، وفرع Merkle هو «الفتح» الذي يكشف جزءًا منها. وتبني ZK-rollups على مخططات التزام أكثر تقدمًا (التزامات كثيرة الحدود والمتجهات) لضغط تنفيذ دفعة كاملة من المعاملات في إثبات رخيص التحقق على السلسلة، وهو الموضوع الذي يغطيه بالتفصيل المعرفة الصفرية المثالية مقابل الحسابية.

مقارنة: الأساسيات التشفيرية للبلوكتشين

كيف يرتبط هذا بالنطاقات المُرمَّزة

كل واحدة من الأساسيات دي بتظهر مباشرة لما ترمّز نطاق. الـNFT اللي بيمثل الملكية بتحميه قواعد تفويض الحساب والتوكن على السلسلة. لو حساب مملوك خارجيًا (EOA) هو اللي محتفظ بيه، فالمفتاح الخاص للحساب بيفوّض إجراءات الحساب؛ أما حساب العقد فما عندوش مفتاح خاص وبيتحكم فيه الكود (ethereum.org، حسابات Ethereum). وفي توكن ERC-721، يقدر عنوان معتمد أو مشغّل يبدأ النقل كمان (ERC-721). علشان كده محافظ الأجهزة والحفظ الدقيق لـالعبارة الأولية (عبارة الاسترداد) مهمين لما تكون الملكية في EOA تحت سيطرتك مباشرة، بينما محافظ العقود الذكية والمحافظ الحاضنة بتضيف حدود تفويض وثقة مختلفة. وبيعيش سجل ملكية النطاق في حالة مرتبطة بالتزامات Merkle نفسها اللي بتحمي كل رصيد حساب وكل عقد ذكي على السلسلة، وده بالتحديد اللي بيدي النطاق المُرمَّز قابلية كشف العبث نفسها اللي عند أي أصل تاني على السلسلة: قابل للنقل والتحقق، وملكيته قابلة للإثبات من غير ما تكون قاعدة بيانات المُسجِّل هي المصدر الوحيد للحقيقة.

كما يوضح فهم هذه الأساسيات ما الذي يغيره الترميز وما الذي لا يغيره: فسجل DNS الخاص بالنطاق وحالته في السجل ما زالا يتبعان قواعد ICANN، لكن إثبات ملكيته يعمل الآن بالتشفير الموضح أعلاه بدل حساب المُسجِّل المحمي بتسجيل دخول. استكشف الصورة الأوسع في آليات توافق البلوكتشين وأساليب توسيع نطاق البلوكتشين، أو ابدأ الترميز على namefi.io.

المصادر ومزيد من القراءة

• Bitcoin Developer Guide — Block Chain، التسلسل عبر SHA256(SHA256()) لرأس الكتلة السابق
• Bitcoin — Bitcoin: A Peer-to-Peer Electronic Cash System، إعادة كتابة تاريخ إثبات العمل والعمل التراكمي
• Bitcoin Developer Reference — Block Chain، بناء جذر Merkle
• Bitcoin Developer Guide — Operating Modes، SPV وفروع Merkle
• ethereum.org — Ethereum Accounts، ECDSA واشتقاق العناوين بـ Keccak-256؛ والتحكم في EOA وحسابات العقود
• ethereum.org — Merkle Patricia Trie، جذور الحالة/المعاملات/الإيصالات
• ethereum.org — Danksharding، التزامات كثيرات الحدود KZG
• EIP-4844 — Shard Blob Transactions، التزامات blobs وإثباتاتها وإتاحتها في طبقة الإجماع
• EIP-7594 — PeerDAS، إثباتات الخلايا وأخذ عينات إتاحة البيانات
• ERC-721 — Non-Fungible Token Standard، ملكية التوكنات والعناوين المعتمدة والمشغّلون
• EIP-2 — Homestead Hard-fork Changes، قيود توقيع secp256k1
• EIP-2537 — Precompile for BLS12-381 curve operations
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)، مخطط Ed25519 ومنحناه ومستوى أمانه
• SEC 2: Recommended Elliptic Curve Domain Parameters — secg.org
• NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management، مستويات الأمان المتقاربة لـECC وRSA
• The Eth2 Book — Signatures and BLS aggregation
• NIST — NIST Releases First 3 Finalized Post-Quantum Encryption Standards