تاريخ العملات الرقمية: من Cypherpunks إلى Bitcoin

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

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

وسوف نناقش في هذا المقال ما يلي:

• المشكلة الأصلية لأي نقد رقمي: الإنفاق المزدوج Double Spending، والثقة بالجهة المصدرة، والخصوصية.
• David Chaum والتوقيع الأعمى Blind Signature، ولماذا أفلست DigiCash رغم أن تقنيتها كانت جيدة، مع تجربة توقيع أعمى حقيقية.
• e-gold وLiberty Reserve: ماذا يحدث عندما تملك شركة واحدة السجل كله.
• حركة Cypherpunks وبيانها، وطابع Hashcash الذي اخترع إثبات العمل Proof of Work لمحاربة البريد المزعج، مع تجربة تعدين طوابع حقيقية.
• b-money وbit gold: الأفكار التي اقتربت من الحل ولم تكتمل.
• ورقة Bitcoin سنة 2008، وما الذي جمعته من كل ما سبق، مع قراءة كتلة التكوين Genesis Block بأنفسنا.
• السنوات الأولى، وEthereum والعقود الذكية، والحوادث الكبيرة الموثقة، وموقف الجهات الرسمية في المملكة.
• جدول قرار وقائمة أسئلة تستخدمها مع فريقك عندما يعرض عليكم أي مشروع عملة رقمية جديد.

والصورة التالية تبين الخط الزمني الذي سوف نمشي عليه، مقسماً إلى أربع مراحل متداخلة:

المشكلة الأصلية: لماذا يصعب صنع نقد رقمي؟

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

والحلم الذي طارده المهندسون منذ الثمانينات هو نقد له خصائص الورقة النقدية ويعمل عبر الشبكة، وهنا تظهر ثلاث مشاكل متشابكة يجب أن يحلها أي تصميم:

• الإنفاق المزدوج Double Spending: الملف الرقمي يمكن نسخه، فإذا كانت «العملة» مجرد ملف أو رقم، فما الذي يمنع صاحبها من إرسال نفس النسخة إلى بائعين مختلفين؟ والجواب البسيط هو أن نسأل جهة مركزية في كل دفعة: «هل صرفت هذه العملة من قبل؟»، وهذا هو بالضبط ما يحاول النقد الرقمي التخلص منه.
• الثقة بالجهة المصدرة Trusted Issuer: من يصدر العملة؟ ومن يضمن أنه لن يصدر منها ما يشاء؟ ومن يضمن أنه لن يغلق أبوابه غداً أو تغلقه جهة قضائية؟
• الخصوصية Privacy: السجل المركزي يرى كل شيء، فيعرف من دفع لمن ومتى وكم، والنقد الورقي لا يعرف شيئاً من ذلك.

ولاحظ أن هذه المشاكل تتعارض فيما بينها: أسهل طريقة لمنع الإنفاق المزدوج هي جهة مركزية ترى كل شيء، وهذا يضر الخصوصية ويجعل الجهة نقطة فشل واحدة Single Point of Failure. وكل محاولة سوف نراها في هذا المقال اختارت توازناً مختلفاً بين الثلاث، وهذا هو المنظار الذي سوف تنظر به إلى كل مرحلة في هذا التاريخ.

David Chaum والتوقيع الأعمى Blind Signature

في أغسطس 1982 قدم عالم التشفير David Chaum في مؤتمر Crypto 82 ورقة بعنوان Blind Signatures for Untraceable Payments، وهي الورقة التي يبدأ منها تاريخ النقد الرقمي عادة. والفكرة التي جاء بها أن البنك يستطيع أن يوقع العملة الرقمية دون أن يرى رقمها، فيضمن قيمتها دون أن يعرف لاحقاً من صرفها. وحتى نفهم لماذا هذا مهم، تخيل أنك تضع ورقة داخل ظرف مبطن بورق الكربون، ثم تعطي الظرف المغلق لموظف البنك فيختم عليه من الخارج، فينطبع الختم على الورقة التي في الداخل دون أن يراها الموظف، ثم تفتح الظرف في بيتك فتجد ورقة مختومة بختم البنك الحقيقي، والبنك لا يعرف أي ورقة كانت.

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

تجربة عملية: توقيع أعمى بمفتاح RSA

الآن سوف نقوم بتنفيذ الفكرة بالرياضيات الحقيقية التي تقف خلفها، باستخدام مفتاح RSA وبالشكل الذي شرحه Chaum. والكود التالي للتعليم فقط ويستخدم RSA دون حشو Padding، وهذا غير آمن في أي نظام حقيقي، وقد شرحنا لماذا تستخدم المكتبات المراجعة ولا تكتب التشفير بنفسك في مقال التشفير للمطورين. احفظ الملف التالي باسم blind.py:

# Chaum's blind signature (1982) with textbook RSA, to see the idea only.
# A real system uses padding and a vetted library; never this code.
import hashlib, secrets, math
from cryptography.hazmat.primitives.asymmetric import rsa

key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
n = key.public_key().public_numbers().n
e = key.public_key().public_numbers().e
d = key.private_numbers().d

def H(b):  # hash the coin serial to a number below n
    return int.from_bytes(hashlib.sha256(b).digest(), "big")

serial = secrets.token_bytes(16)          # the customer picks the coin's serial number
m = H(serial)
while True:                               # blinding factor r, coprime with n
    r = secrets.randbelow(n - 2) + 2
    if math.gcd(r, n) == 1:
        break
blinded = (m * pow(r, e, n)) % n          # what the bank sees
print("serial (customer only):", serial.hex())
print("bank sees            :", hex(blinded)[:42], "...")

s_blinded = pow(blinded, d, n)            # bank signs and debits the account
s = (s_blinded * pow(r, -1, n)) % n       # customer removes r
print("unblinded signature  :", hex(s)[:42], "...")
print("valid bank signature :", pow(s, e, n) == m)
print("bank can link it     :", s_blinded == s)

spent = set()
def deposit(serial, sig):
    if pow(sig, e, n) != H(serial):
        return "rejected: bad signature"
    if serial in spent:
        return "rejected: double spend"
    spent.add(serial)
    return "accepted"
print("shop deposits coin   :", deposit(serial, s))
print("same coin again      :", deposit(serial, s))

ونشغله في Container مؤقت حتى لا نثبت أي شيء على الجهاز، مع تثبيت مكتبة cryptography بإصدار محدد لنولد بها مفتاح RSA:

docker run --rm --name lab-history-py -v "$PWD:/lab" -w /lab python:3.13.16-slim \
  bash -c "pip install -q --root-user-action=ignore cryptography==46.0.3 && python blind.py"

والمخرج سوف يكون كما يلي، والأرقام تختلف في كل تشغيل لأن المفتاح والرقم وعامل التعمية عشوائية:

serial (customer only): 7f3a4658957a225f106c2cd973eccd96
bank sees            : 0x402c2aa428ed6cedbd463a2c8c3443efeccae160 ...
unblinded signature  : 0x9d1b50a1ebb6682473bfeedb0c421375454080b9 ...
valid bank signature : True
bank can link it     : False
shop deposits coin   : accepted
same coin again      : rejected: double spend

في الإعداد أعلاه لاحظ التالي:

• العميل يختار رقم العملة serial بنفسه، ثم يضرب هاشه في عامل التعمية r مرفوعاً للأس العام، فيرى البنك رقماً عشوائياً تماماً 0x402c2aa4… لا علاقة ظاهرة له بالرقم الحقيقي.
• البنك يوقع الرقم المغطى بمفتاحه الخاص d، وفي النظام الحقيقي يخصم في نفس اللحظة قيمة العملة من حساب العميل، لأن التوقيع هو الذي يعطي العملة قيمتها.
• العميل يضرب التوقيع في معكوس r فيزول الغطاء، ويبقى توقيع صحيح على الرقم الأصلي، والسطر valid bank signature : True يثبت ذلك بالمفتاح العام وحده.
• السطر bank can link it : False هو قلب الفكرة: التوقيع الذي يظهر عند الإيداع ليس هو التوقيع الذي أنتجه البنك، فلا يستطيع البنك أن يربط بين السحب والإيداع.
• الإيداع الثاني لنفس العملة رفض بسبب القائمة spent، وهذه القائمة هي التي تمنع الإنفاق المزدوج، ولكنها تعيش عند البنك وحده.

والصورة التالية تجمع الخطوات الأربع بالقيم التي ظهرت في المخرج:

والآن جرب بنفسك ماذا يحدث إذا حاول شخص أن يصنع عملة دون أن يمر على البنك: غير السطر الذي يحسب s ليضع رقماً عشوائياً، وسوف تجد أن الإيداع يرجع rejected: bad signature، لأن أحداً لا يستطيع إنتاج توقيع يتحقق بالمفتاح العام دون المفتاح الخاص. وهذا يبين أن التشفير عند Chaum كان صحيحاً تماماً، والمشكلة لم تكن فيه.

DigiCash: تقنية جيدة وشركة أفلست

أسس Chaum شركة DigiCash في هولندا لتحويل الفكرة إلى منتج اسمه ecash، وعملت معها بنوك قليلة، ثم أفلست الشركة في سبتمبر 1998 كما يذكر مقال مترجم من مجلة Next! الهولندية نشر في القائمة البريدية للتشفير في فبراير 1999 بعنوان «How DigiCash Blew Everything». والدرس المهم هنا أن النظام كان يحتاج بنكاً يشارك فيه، وكل بنك جديد يحتاج تفاوضاً وترخيصاً، وكل تاجر يحتاج حساباً عند بنك مشارك، وبالتالي بقي النقد الرقمي رهينة لنموذج عمل شركة واحدة، فلما تعثرت الشركة تعثر النقد معها. وتذكر هذه الملاحظة جيداً، لأنها سوف تتكرر بأشكال مختلفة حتى سنة 2022.

e-gold وLiberty Reserve: عندما تملك شركة واحدة السجل

في التسعينات والعقد الذي تلاه ظهر نوع آخر أبسط بكثير من فكرة Chaum: شركة تفتح لك حساباً بعملة خاصة بها، مثل «غرام ذهب» في e-gold أو وحدة خاصة في Liberty Reserve، وتحول هذه الوحدات بين الحسابات داخل قاعدة بياناتها. وتقنياً هذا هو أبسط تصميم ممكن، فالإنفاق المزدوج لا يحدث لأن قاعدة البيانات مركزية، والتحويل فوري وبلا رسوم تقريباً. ولكن مالك السجل يملك كل شيء، والجهات الرقابية ترى في هذه الشركات جهات تحويل أموال يجب أن تخضع لنفس قواعد مكافحة غسل الأموال التي يخضع لها البنك.

وقد أعلنت وزارة العدل الأمريكية في يوليو 2008 أن e-gold والشركة المرتبطة بها ومؤسسها أقروا بالذنب في تهم التآمر لغسل الأموال وتشغيل نشاط تحويل أموال دون ترخيص. ثم جاءت Liberty Reserve، وفي مايو 2016 أعلنت الوزارة الحكم على مؤسسها بالسجن 20 سنة بعد أن أغلقت السلطات الشركة سنة 2013. وقد يتساءل البعض: ما علاقة هذا بالتقنية؟ والإجابة أن السجل المركزي له نقطة واحدة يمكن إغلاقها، سواءً كان الإغلاق بسبب إفلاس كما في DigiCash أو بقرار قضائي كما في e-gold وLiberty Reserve، والمستخدم في الحالتين لا يملك إلا رقماً في قاعدة بيانات غيره.

حركة Cypherpunks: الخصوصية تحتاج كوداً وليس قوانين فقط

في نفس الفترة كانت هناك قائمة بريدية اسمها Cypherpunks يجتمع فيها مبرمجون وعلماء تشفير يؤمنون بأن الخصوصية على الشبكة لن تأتي من وعود الشركات والحكومات، وإنما من أدوات تشفير يكتبونها وينشرونها بأنفسهم. وفي 9 مارس 1993 كتب Eric Hughes A Cypherpunk's Manifesto، وفيه جملتان تلخصان علاقة الحركة بالنقد الرقمي: أن الخصوصية ضرورية لمجتمع مفتوح في العصر الإلكتروني، وأن الخصوصية في مجتمع مفتوح تحتاج أنظمة معاملات مجهولة الهوية Anonymous Transaction Systems. وفي البيان أيضاً العبارة المشهورة «Cypherpunks write code»، أي أن أعضاء الحركة لا يكتفون بالنقاش، وإنما يكتبون الكود.

وهذه القائمة هي المكان الذي ظهرت فيه أغلب الأفكار التي سوف نراها في الأقسام التالية، ولهذا السبب يبدأ كثير من الناس تاريخ العملات الرقمية من Cypherpunks وليس من Bitcoin. ولاحظ أن الدافع الأصلي كان الخصوصية والاستقلال عن الوسيط، وليس المضاربة، وهذه ملاحظة مفيدة عندما تشرح لفريقك لماذا صمم Bitcoin بالشكل الذي صمم به: الهدف الأول في ورقته هو الدفع بين طرفين دون مؤسسة مالية في المنتصف.

Hashcash: إثبات العمل Proof of Work ضد البريد المزعج

المشكلة التالية جاءت من مكان لا علاقة له بالمال: البريد المزعج Spam. فإرسال رسالة بريد يكلف المرسل لا شيء تقريباً، لذلك يرسل صاحب البريد المزعج ملايين الرسائل، وفي سنة 1997 اقترح Adam Back حلاً سماه Hashcash: أن يرفق المرسل بكل رسالة «طابعاً» يكلفه بضع ثوان من عمل المعالج، ويستطيع المستقبل أن يتحقق منه في جزء من الثانية. فالمستخدم العادي الذي يرسل عشرين رسالة في اليوم لن يشعر بالتكلفة، أما من يرسل مليون رسالة فيحتاج مليون طابع، وكل طابع مربوط بعنوان مستقبل واحد. ونشر Back الورقة التي تشرح الفكرة سنة 2002 بعنوان «Hashcash - a denial of service counter-measure»، وهي المرجع رقم 6 في ورقة Bitcoin نفسها.

والطابع نص بسيط فيه سبعة حقول مفصولة بنقطتين: رقم الإصدار، ثم عدد البتات الصفرية المطلوبة، ثم التاريخ، ثم المورد Resource وهو عادة عنوان المستقبل، ثم حقل امتداد فارغ، ثم قيمة عشوائية، ثم عداد Counter. والمرسل يغير العداد مرة بعد مرة ويحسب هاش SHA-1 للنص كله، حتى يجد نصاً يبدأ هاشه بالعدد المطلوب من البتات الصفرية، ولا توجد طريقة لتوقع العداد الصحيح إلا التجربة، لأن الهاش لا يمكن توقعه كما شرحنا في قسم دالة الهاش.

تجربة عملية: نصنع طوابع Hashcash ونتحقق منها

الكود التالي يصنع طوابع بثلاث صعوبات مختلفة، ثم يتحقق من الطابع الأخير كما يفعل المستقبل، ثم يحاول أن يستخدم نفس الطابع لعنوان آخر. احفظه باسم hashcash.py:

import hashlib, os, base64, time, sys

def mint(resource, bits, date="261028"):
    rand = base64.b64encode(os.urandom(9)).decode()
    counter = 0
    start = time.perf_counter()
    while True:
        stamp = f"1:{bits}:{date}:{resource}::{rand}:{counter:x}"
        digest = hashlib.sha1(stamp.encode()).digest()
        value = int.from_bytes(digest, "big")
        if value >> (160 - bits) == 0:          # the first `bits` bits are zero
            return stamp, counter + 1, time.perf_counter() - start, digest.hex()
        counter += 1

def check(stamp):
    bits = int(stamp.split(":")[1])
    value = int.from_bytes(hashlib.sha1(stamp.encode()).digest(), "big")
    return value >> (160 - bits) == 0

for bits in (16, 20, 22):
    stamp, tries, secs, h = mint("[email protected]", bits)
    print(f"bits={bits} tries={tries:>8} time={secs:6.2f}s")
    print("  stamp:", stamp)
    print("  sha1 :", h)
print("receiver check:", check(stamp))
forged = stamp.replace("[email protected]", "[email protected]")
print("same stamp for another address:", check(forged))

ثم شغله في نفس ال Image:

docker run --rm --name lab-history-py -v "$PWD:/lab" -w /lab python:3.13.16-slim python hashcash.py

والمخرج سوف يكون كما يلي، والأعداد والأوقات تختلف في كل تشغيل ومن جهاز لآخر:

bits=16 tries=   58062 time=  0.28s
  stamp: 1:16:261028:[email protected]::HsDxPc2OJcGa:e2cd
  sha1 : 0000cb4013cd502e9a6ef81c7694c58573a74dab
bits=20 tries= 1944030 time= 11.79s
  stamp: 1:20:261028:[email protected]::YloAo8u7egn6:1da9dd
  sha1 : 000003072c8a9bbdaef710901cea8dc22081709d
bits=22 tries= 2435850 time= 15.17s
  stamp: 1:22:261028:[email protected]::2BmbfEINSjKO:252b09
  sha1 : 000000124e200977fcfd720efcd5e32f3227110d
receiver check: True
same stamp for another address: False

في الإعداد أعلاه لاحظ التالي:

• كل 4 بتات صفرية تساوي حرف 0 واحداً في ترميز Hex، لذلك الهاش في صعوبة 16 بت يبدأ بأربعة أصفار، وفي 20 بت بخمسة، وفي 22 بت بخمسة أصفار ثم حرف أقل من 4.
• العدد المتوقع للمحاولات يتضاعف مع كل بت إضافي، أي قرابة 65 ألف محاولة لصعوبة 16 بت وقرابة مليون لصعوبة 20 بت، ولكن الرقم الفعلي حظ: في هذا التشغيل احتاجت صعوبة 20 بت قرابة مليوني محاولة، واحتاجت صعوبة 22 بت قرابة مليونين ونصف فقط، وهو أقل من نصف المتوسط المتوقع لها.
• التحقق عند المستقبل هاش واحد، أي أن التكلفة غير متماثلة Asymmetric: المرسل يدفع ملايين العمليات والمستقبل يدفع عملية واحدة، وهذه هي الخاصية التي سوف يبني عليها Bitcoin.
• عندما غيرنا العنوان في نفس الطابع فشل التحقق، لأن العنوان جزء من النص الذي حسبنا هاشه، وبالتالي الطابع المدفوع لعنوان لا يصلح لعنوان آخر.

والصورة التالية تلخص الطرفين والأرقام:

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

b-money وbit gold: أفكار اقتربت من الحل

b-money: سجل يحفظه كل المشاركين

في سنة 1998 نشر Wei Dai على موقعه نصاً قصيراً بعنوان b-money، وهو المرجع رقم 1 في ورقة Bitcoin. والجديد فيه أنه يتخلص من البنك تماماً: يقترح أن يصنع أي شخص المال بنشر حل لمسألة حسابية لم تحل من قبل، وأن يساوي عدد الوحدات المصنوعة تكلفة الجهد الحسابي، وأن تحفظ الأرصدة في سجل لا تملكه جهة واحدة. وفي النص بروتوكولان: الأول أن يحفظ كل مشارك قاعدة بيانات منفصلة بما يملكه كل اسم مستعار Pseudonym، ويصف Dai نفسه هذا البروتوكول بأنه غير عملي لأنه يحتاج قناة بث Broadcast متزامنة لا يمكن تعطيلها، والثاني أن تحفظ الحسابات مجموعة من المشاركين يسميهم الخوادم Servers.

ولاحظ هنا أن b-money وضعت يدها على المشكلة الصعبة بالضبط: إذا كان كل مشارك يحفظ نسخته من السجل، فكيف يتفق الجميع على ترتيب واحد للمعاملات والرسائل تصل بترتيب مختلف إلى كل واحد؟ وهذا هو نفس سؤال الإجماع Consensus الذي شرحناه في مقال الأنظمة الموزعة، والنص افترض وجود قناة تحله، ولم يقدم آلية تعمل بين غرباء.

bit gold: سلسلة ملكية مبنية على العمل

وفي ديسمبر 2005 كتب Nick Szabo في مدونته مقالاً بعنوان Bit gold، يبدأ من ملاحظة أن المال الحالي يعتمد على الثقة بطرف ثالث في قيمته، ويقترح «ذهباً رقمياً» يصنع بإثبات العمل: يحسب المالك سلسلة من نتيجة دالة قياس Benchmark Function على بتات بداية علنية، ويختم النتيجة زمنياً عند عدة خدمات ختم موزعة حتى لا يعتمد على خدمة واحدة. والفكرة الأهم أن آخر سلسلة bit gold صنعت تعطي بتات البداية Challenge Bits للسلسلة التالية، فتتكون سلسلة مربوطة، وأن ملكية الوحدة لا تأتي من امتلاك البتات نفسها، وإنما من موقع المالك في «سلسلة ملكية لا يمكن تزويرها» Unforgeable Chain of Title.

وهنا يقترب التصميم من Bitcoin كثيراً: إثبات عمل، وسلسلة كل حلقة فيها تعتمد على ما قبلها، وسجل ملكية. ولكن بقي سؤالان دون حل عملي: من يحفظ سجل الملكية ويتفق عليه؟ وما العمل إذا اختلفت خدمات الختم الزمني؟ وبقيت bit gold مقالاً لم يتحول إلى شبكة تعمل.

وفي نفس الفترة تقريباً بنى Hal Finney نظاماً سماه RPOW، أي إثبات عمل قابل لإعادة الاستخدام Reusable Proofs of Work، يحول طابع Hashcash إلى رمز يمكن نقله، ويحل الإنفاق المزدوج بخادم يشغل كوداً يمكن لأي شخص أن يتحقق منه عن بعد. وهذا حل ذكي، ولكنه في النهاية خادم واحد، أي نفس نقطة الفشل التي رأيناها عند DigiCash.

والجدول التالي في الصورة يضع كل المحاولات أمام الأسئلة الأربعة:

ورقة Bitcoin: ما الذي جمعته؟

في 31 أكتوبر 2008 أرسل شخص أو مجموعة باسم Satoshi Nakamoto إلى القائمة البريدية للتشفير رسالة فيها رابط الورقة بعنوان «Bitcoin: A Peer-to-Peer Electronic Cash System»، وهي تسع صفحات فقط. والجملة الأولى في الورقة تقول إن الهدف نقد إلكتروني يرسل مباشرة من طرف لآخر دون أن يمر على مؤسسة مالية، ثم تقول الورقة صراحة إن التوقيعات الرقمية تحل جزءاً من المشكلة، ولكن الفائدة تضيع إذا بقي طرف موثوق مطلوباً لمنع الإنفاق المزدوج. أي أن الورقة تبدأ من نفس المشكلة التي توقف عندها Chaum بالضبط.

والطريف لجلستك أن قائمة المراجع في نهاية الورقة تحكي التاريخ الذي مررنا عليه: المرجع الأول b-money من Wei Dai سنة 1998، والمراجع من الثاني إلى الخامس أوراق في الختم الزمني Timestamping، منها ورقة Haber وStornetta سنة 1991 «How to time-stamp a digital document» التي تربط الوثائق بسلسلة هاش، والمرجع السادس Hashcash، والسابع ورقة Ralph Merkle سنة 1980 التي جاءت منها شجرة Merkle. فالورقة لا تدعي اختراع القطع، وإنما تجمعها، والصورة التالية تبين ذلك:

إذن ما الجديد؟ الجديد أن إثبات العمل لم يعد هو العملة كما في bit gold وRPOW، وإنما صار صوتاً في ترتيب المعاملات: كل عقدة تجمع المعاملات في كتلة، وتبحث عن Nonce يجعل هاش الكتلة أصغر من الهدف، وكل العقد تتبنى السلسلة التي فيها أكبر عمل متراكم. وبهذا الشكل حلت الورقة مشكلة b-money بالضبط: لا حاجة لقناة بث متزامنة، لأن الخلاف المؤقت بين العقد يحسمه العمل المتراكم، ولا حاجة لهوية المشاركين، لأن الصوت يحتاج كهرباء ولا يمكن الحصول عليه بفتح ألف حساب وهمي. ثم ربطت الورقة الحافز بالأمان: من يجد الكتلة يحصل على مكافأة بعملات جديدة، فيصبح من مصلحة أصحاب الأجهزة أن يحموا السلسلة بدلاً من مهاجمتها. أما كيف يحسب الهدف ولماذا ينتظر الناس عدة تأكيدات فقد شرحناه في مقال الإجماع.

كتلة التكوين Genesis Block: نقرؤها بأنفسنا

في 3 يناير 2009 أنشئت أول كتلة في Bitcoin، وفي 8 يناير أعلن Satoshi في نفس القائمة صدور الإصدار 0.1، وكتب أنه نظام نقد إلكتروني يستخدم شبكة نظير لنظير Peer-to-Peer لمنع الإنفاق المزدوج، وأنه لا يوجد فيه سيرفر أو جهة مركزية، وأنه يعمل على Windows فقط في البداية. والآن سوف نتحقق من كتلة التكوين بأنفسنا بدلاً من أن نثق بما يكتب عنها، وهذا هو المبدأ الذي قام عليه النظام كله.

رأس الكتلة Block Header في Bitcoin 80 بايت فقط: الإصدار، وهاش الكتلة السابقة، وجذر Merkle، والوقت، والهدف المضغوط في حقل bits، وال Nonce. وقيم كتلة التكوين مكتوبة في ملف chainparams.cpp في كود Bitcoin Core، فنعيد بناء الرأس منها ونحسب هاشه. احفظ الملف التالي باسم genesis.py:

import hashlib, struct
version, prev = 1, bytes(32)
merkle = bytes.fromhex("4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b")[::-1]
time_, bits, nonce = 1231006505, 0x1d00ffff, 2083236893
header = struct.pack("<I", version) + prev + merkle + struct.pack("<III", time_, bits, nonce)
h = hashlib.sha256(hashlib.sha256(header).digest()).digest()[::-1].hex()
print("header bytes:", len(header))
print("block hash  :", h)
exp, mant = bits >> 24, bits & 0xffffff
target = mant * 256 ** (exp - 3)
print("target      :", f"{target:064x}")
print("hash < target:", int(h, 16) < target)

ثم شغله:

docker run --rm --name lab-history-py -v "$PWD:/lab" -w /lab python:3.13.16-slim python genesis.py

والمخرج سوف يكون كما يلي:

header bytes: 80
block hash  : 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
target      : 00000000ffff0000000000000000000000000000000000000000000000000000
hash < target: True

في الإعداد أعلاه لاحظ التالي:

• الهاش الناتج 000000000019d668… هو نفس هاش كتلة التكوين المكتوب في chainparams.cpp، أي أننا تحققنا منها بستة أسطر دون أن نثق بأي موقع.
• Bitcoin يحسب SHA-256 مرتين Double SHA-256، ويكتب الحقول بترتيب البايتات الصغير أولاً Little Endian، لذلك نقلب جذر Merkle قبل البناء ونقلب الهاش عند العرض.
• القيمة 0x1d00ffff هي أسهل هدف سمح به Bitcoin، أي الصعوبة 1، والهاش أصغر منه، وقد احتاج Satoshi إلى Nonce قيمته 2083236893، أي قرابة ملياري محاولة، وهي نفس فكرة Hashcash ولكن بـ SHA-256.

والآن نقرأ المعاملة الوحيدة في كتلة التكوين من Bitcoin Core نفسه. والبرنامج لا ينشر Docker Image رسمية، وال Image المعروفة bitcoin/bitcoin تقول في صفحتها إنها غير رسمية ومخصصة للاختبار، لذلك نشغلها في وضع regtest، وهو شبكة خاصة على جهازك لا تتصل بأحد، وقد شرحناه في مقال البلوكتشين للمبتدئين:

docker run -d --name lab-history-btc bitcoin/bitcoin:31.1 bitcoind -regtest -printtoconsole=0
alias btc='docker exec --user bitcoin lab-history-btc bitcoin-cli -regtest'
btc getblockhash 0
btc getblock $(btc getblockhash 0) 2 | grep -m1 '"coinbase"'
btc getblockheader $(btc getblockhash 0) | grep -E '"(time|nonce|bits|merkleroot)"'

والمخرج سوف يكون كما يلي:

0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206
    "coinbase": "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73"
  "merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
  "time": 1296688602,
  "nonce": 2,
  "bits": "207fffff",

لاحظ أن هاش كتلة التكوين في regtest يختلف عن الشبكة الرئيسية، لأن الوقت وال Nonce والهدف مختلفة، أما جذر Merkle فهو نفسه 4a5e1e4b…، والسبب أن الشبكات كلها تستخدم نفس معاملة المكافأة Coinbase Transaction الأصلية. والحقل coinbase بيانات حرة يضعها من ينشئ الكتلة، فنحول ال Hex إلى نص ونتجاوز أول 8 بايتات، وهي أرقام يحتاجها النص البرمجي Script وليست جزءاً من الرسالة:

docker run --rm --name lab-history-py python:3.13.16-slim python -c "print(bytes.fromhex('04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73')[8:].decode())"

والمخرج سوف يكون كما يلي:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

وهذا عنوان صحيفة The Times البريطانية يوم 3 يناير 2009 عن خطة إنقاذ ثانية للبنوك، ووضعه في الكتلة يثبت أنها لم تنشأ قبل ذلك اليوم، فهو ختم زمني بالمعنى الحرفي، ويقرؤه كثيرون أيضاً كتعليق على الأزمة المالية التي كانت في أوجها. والآن نجرب شيئاً لا يعرفه كثيرون: هل يمكن صرف الخمسين وحدة التي حصلت عليها كتلة التكوين؟

btc gettxout 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b 0
btc gettxoutsetinfo | grep -E '"(height|txouts|total_amount)"'

والمخرج سوف يكون كما يلي، والأمر الأول لا يطبع شيئاً:

  "height": 0,
  "txouts": 0,
  "total_amount": 0.00000000,

الأمر gettxout يسأل عن مخرج غير منفق، ولم يرجع شيئاً، ومجموعة المخرجات غير المنفقة UTXO Set فيها صفر مخرجات ومجموعها صفر، رغم أن الكتلة تقول إن المكافأة 50 وحدة. والآن ماذا يحدث إذا أنشأنا كتلة واحدة جديدة؟

btc createwallet lab
btc generatetoaddress 1 $(btc getnewaddress)
btc gettxoutsetinfo | grep -E '"(height|txouts|total_amount)"'

والمخرج سوف يكون كما يلي، بعد سطر اسم المحفظة:

[
  "166afc2b3c4bb70251ddee6788619d069ca28fee096808b7b6893316105c6787"
]
  "height": 1,
  "txouts": 1,
  "total_amount": 50.00000000,

مكافأة الكتلة الجديدة دخلت مجموعة المخرجات غير المنفقة فوراً، أما مكافأة كتلة التكوين فلم تدخلها أبداً، والسبب أن الكود الأصلي لم يضف معاملة كتلة التكوين إلى قاعدة بيانات المعاملات، وبقي هذا السلوك في كل الإصدارات حتى لا تتغير قواعد الإجماع، لذلك الخمسون وحدة الأولى في تاريخ Bitcoin لا يمكن صرفها. وسوف نشرح المخرجات غير المنفقة UTXO بالتفصيل في مقال كيف يعمل Bitcoin. احذف ال Container عندما تنتهي:

docker rm -f -v lab-history-btc

السنوات الأولى: من بيتزا إلى ثغرة في الكود

في السنة الأولى لم يكن لهذه الوحدات أي سعر، فهي مجرد أرقام يتبادلها بعض المهتمين بالتشفير، وأول مرة اشتريت بها سلعة حقيقية موثقة في منتدى Bitcoin نفسه: في 18 مايو 2010 كتب مبرمج اسمه Laszlo Hanyecz موضوعاً بعنوان Pizza for bitcoins? يعرض فيه 10,000 وحدة مقابل قطعتي بيتزا كبيرتين، وفي 22 مايو كتب في نفس الموضوع أنه أتم الصفقة فعلاً. وأهمية هذه القصة لجلستك ليست في السعر، وإنما في أن الوحدة انتقلت لأول مرة من «تجربة تقنية» إلى شيء يقبله شخص آخر مقابل سلعة، وهذا هو التعريف العملي للنقد.

وبعد ثلاثة أشهر جاء أول درس قاس في أن الكود هو القواعد: في أغسطس 2010 اكتشف المستخدمون كتلة فيها معاملة أنشأت أكثر من 184 مليار وحدة، بسبب تجاوز في سعة العدد الصحيح Integer Overflow عند جمع قيم المخرجات، والثغرة مسجلة اليوم باسم CVE-2010-5139، ووصفها الرسمي أن الإصدارات قبل 0.3.11 تسمح للمهاجم بتجاوز القيود الاقتصادية وإنشاء عملات كثيرة بمعاملة مصممة لذلك. وكما يشرح سجل الحادثة في ويكي Bitcoin صدر إصدار مصحح خلال خمس ساعات من اكتشافها، وتبنت العقد سلسلة جديدة لا تحتوي تلك الكتلة، فاختفت المعاملة من التاريخ. والدرس أن الأمان التشفيري لا يحمي من خطأ في منطق التحقق، وأن «السلسلة لا تتغير» صحيحة فقط ما دام أغلب العقد متفقين على عدم تغييرها.

Ethereum: من نقد إلى حاسوب يشغل برامج

بعد Bitcoin ظهرت مئات العملات التي تغير في الإعدادات، مثل وقت الكتلة أو دالة الهاش، ولكن الخطوة الكبيرة التالية جاءت من فكرة مختلفة: إذا كانت السلسلة تتفق على ترتيب المعاملات، فلماذا لا تتفق أيضاً على نتيجة تنفيذ برنامج؟ وهذا هو العقد الذكي Smart Contract الذي عرفه Nick Szabo في التسعينات كما ذكرنا في المقال الأول. وكما يذكر السجل التقني لترقيات Ethereum نشر Vitalik Buterin ورقة Ethereum في 27 نوفمبر 2013، وانطلقت الشبكة الأولى Frontier في 30 يوليو 2015، وفيها آلة افتراضية EVM تنفذ برامج تكتب غالباً بلغة Solidity، وكل عملية لها تكلفة بالغاز Gas.

وجاء الدرس الأول بسرعة: في سنة 2016 استغل مهاجم ثغرة في عقد اسمه The DAO كان يحفظ أموال أعضائه، وسحب منه أكثر من 3.6 مليون ETH بحسب نفس السجل، ولأن العقد لا يمكن تعديله قرر المجتمع تفرعاً صلباً Hard Fork يوم 20 يوليو 2016 عند الكتلة 1,920,000 يعيد الأموال، واستمر جزء من المجتمع على السلسلة القديمة التي صارت Ethereum Classic. وقد ذكرنا الحادثة في مقال البلوكتشين للمبتدئين، والذي يهمنا هنا في الخط الزمني أنها كانت أول مرة يغير فيها مجتمع شبكة عامة كبيرة التاريخ باتفاق اجتماعي، وأنها أظهرت أن «لا مركزية» الشبكة لها حدود يحددها الناس الذين يشغلون العقد.

ثم في 15 سبتمبر 2022 انتقلت Ethereum من إثبات العمل إلى إثبات الحصة Proof of Stake في الحدث المعروف باسم The Merge، كما في صفحة The Merge، فصارت الشبكة الثانية في الحجم تعمل دون تعدين بالكهرباء. وهذا مثال جيد لفريقك على أن قواعد هذه الشبكات ليست ثابتة إلى الأبد، وإنما تتغير بترقيات يتفق عليها المطورون ومشغلو العقد.

الرموز Tokens والجهات الرقابية

العقود الذكية جعلت إصدار «رمز» Token جديد أمراً يحتاج بضعة أسطر من الكود، وهنا يعود السؤال الثاني الذي بدأنا به: لماذا لا نصدر عملتنا؟ والإجابة التقنية أن ذلك سهل فعلاً، وسوف نكتب رمزاً كاملاً في مقال قادم عن معيار ERC-20، أما الإجابة الحقيقية فهي في النظام وليس في الكود. فبيع رمز للجمهور بوعد عائد يشبه طرح أوراق مالية، وتحويل وحدات بين المستخدمين يشبه تحويل الأموال، وكلاهما نشاط مرخص في أغلب الدول، وقد رأينا ما حدث لشركات التحويل غير المرخصة مثل e-gold.

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

الدروس الصعبة: أين تقع الأخطار فعلاً؟

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

• الحفظ لدى طرف آخر Custody: في Mt. Gox سنة 2014 كما رأينا، وفي FTX سنة 2022، والتي انتهت قضيتها الجنائية بإعلان وزارة العدل الأمريكية في 28 مارس 2024 الحكم على مؤسسها Samuel Bankman-Fried بالسجن 25 سنة. وفي الحالتين عاد العالم إلى مشكلة DigiCash وe-gold نفسها: سجل مركزي عند شركة، والمستخدم يملك رقماً فيه.
• كود العقود الذكية: كما في The DAO، والكود المنشور لا يصلح إلا بنشر عقد جديد أو بتغيير السلسلة نفسها.
• برامج العقد والمحافظ: كما في ثغرة تجاوز القيمة سنة 2010، ولهذا السبب تهتم شبكة Ethereum مثلاً بتنوع العملاء Client Diversity حتى لا يسقط خطأ في برنامج واحد الشبكة كلها.
• النظام والرقابة: كما في e-gold وLiberty Reserve، والتحذير الرسمي في المملكة.

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

أخطاء شائعة في رواية هذا التاريخ

عندما تتحدث عن هذا التاريخ مع زملائك سوف تسمع بعض العبارات الشائعة، وهذه أهمها مع تصحيحها من المصادر نفسها:

• «Bitcoin اخترع البلوكتشين»: الورقة نفسها لا تستخدم كلمة Blockchain أصلاً، وإنما تتحدث عن سلسلة كتل وخادم ختم زمني، وتستشهد بأوراق الختم الزمني منذ سنة 1991، وما جاءت به هو الجمع بين القطع مع قاعدة الإجماع.
• «Bitcoin مجهول الهوية»: الورقة نفسها في القسم العاشر تتحدث عن الخصوصية بإبقاء المفاتيح العامة دون أسماء، وكل معاملة علنية للجميع، أي أن الهوية مستعارة Pseudonymous وليست مجهولة، والنقد الأقرب إلى الخصوصية الحقيقية كان نقد Chaum الذي جربناه، والذي يحتاج بنكاً.
• «كل شيء قبل Bitcoin فشل لأن التقنية كانت ضعيفة»: التجربة التي شغلناها تبين أن تشفير Chaum كان سليماً، والذي أسقط المحاولات المركزية كان نموذج العمل والنظام ونقطة الفشل الواحدة، والذي أوقف المحاولات اللامركزية كان الإجماع.
• «السلسلة لا يمكن أن تتغير»: تغيرت فعلاً في أغسطس 2010 لإصلاح ثغرة، وفي يوليو 2016 بعد The DAO، وفي الحالتين باتفاق أغلب مشغلي العقد، فالأدق أن تغيير الماضي مكلف ويحتاج اتفاقاً واسعاً.

جدول قرار: كيف تقيم مشروعاً جديداً بعين التاريخ؟

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

قائمة تحقق للجلسة الداخلية

وإذا أردت أن تشرح هذا التاريخ لفريقك في جلسة داخلية، فهذه القائمة التي تجعلها مفيدة وليست سرداً للتواريخ:

• ابدأ بالمشاكل الثلاث: الإنفاق المزدوج، والثقة بالمصدر، والخصوصية، واطلب من الفريق أن يصنف تطبيقكم الحالي بها قبل أي تاريخ.
• شغل تجربة التوقيع الأعمى أمامهم، وأظهر السطر bank can link it : False ثم قائمة spent، حتى يروا أين بقيت المركزية.
• شغل تجربة Hashcash بصعوبة 16 ثم 20 بت، واطلب منهم توقع زمن 24 بت قبل التشغيل، فهذا يشرح الصعوبة Difficulty أفضل من أي شريحة.
• تحقق من كتلة التكوين بملف genesis.py، وعلق على أن التحقق المستقل هو جوهر الفكرة كلها.
• اعرض الحوادث مع مصادرها الرسمية فقط: الأمين القضائي لـ Mt. Gox، وسجل ترقيات Ethereum، وصفحة NVD، وبيانات وزارة العدل الأمريكية، وبيان هيئة السوق المالية.
• أنه الجلسة بجدول القرار أعلاه، واتفقوا على أن أي فكرة عملة أو رمز تمر على المستشار القانوني أولاً.
• لا تعرض أي توقع لسعر أي عملة، ولا أي توصية بشراء أو بيع، فهذا خارج هدف الجلسة وخارج اختصاص الفريق التقني.

تدريب عملي

1. عدل hashcash.py ليستخدم SHA-256 بدلاً من SHA-1، وقارن عدد المحاولات لنفس الصعوبة، ثم فسر لماذا لا يتغير المتوسط المتوقع رغم اختلاف الدالة.
2. في blind.py اجعل البنك يحفظ كل التوقيعات التي أنتجها في قائمة، ثم حاول أن تجد التوقيع المودع فيها، وفسر النتيجة.
3. غير قيمة nonce في genesis.py بواحد، وانظر هل ما زال الهاش أصغر من الهدف، وكم صفراً بقي في بدايته.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• كل نقد رقمي يجب أن يحل ثلاث مشاكل متعارضة: الإنفاق المزدوج، والثقة بالمصدر، والخصوصية.
• David Chaum حل الخصوصية والإنفاق المزدوج بالتوقيع الأعمى منذ 1982، ولكن نظامه احتاج بنكاً في كل إيداع، وأفلست DigiCash سنة 1998.
• e-gold وLiberty Reserve كانت سجلات مركزية بسيطة، وانتهت بأحكام قضائية، والدرس أن السجل المركزي نقطة واحدة يمكن إغلاقها.
• Hashcash اخترع إثبات العمل بتكلفة غير متماثلة، وb-money وbit gold اقتربتا من سجل يحفظه الجميع، والذي نقص كان الإجماع بين غرباء.
• ورقة Bitcoin سنة 2008 جمعت القطع القديمة وأضافت قاعدة أطول سلسلة عمل، وكتلة التكوين في 3 يناير 2009 تستطيع التحقق منها بنفسك.
• Ethereum أضافت العقود الذكية، ومعها جاءت حوادث مثل The DAO، والحوادث الكبرى كلها كانت في الحفظ والكود والبرامج والنظام، وليس في التشفير.
• في المملكة صدر تحذير رسمي سنة 2018 بأن العملات الافتراضية غير معتمدة، وأي قرار يجب أن يبنى على النصوص الرسمية السارية.

وفي المقالات القادمة بإذن الله سوف نجيب عن السؤال العملي الذي يأتي بعد هذا التاريخ: هل تحتاج بلوكتشين أصلاً؟ ثم ندخل في التشفير الذي تقوم عليه هذه الشبكات، ثم Bitcoin من الداخل.

دليلكيف يعمل البلوكتشين Blockchain ومتى لا تحتاجهما المشكلة التي يحلها البلوكتشين أصلاً وكيف يعمل من الداخل، ومتى تكون قاعدة البيانات العادية هي الحل الأصح.دليلكيف تتفق شبكة البلوكتشين؟ إثبات العمل وإثبات الحصةكيف تتفق آلاف العقد التي لا يثق بعضها ببعض على سجل واحد، ولماذا يكلف الغش كهرباء في شبكة ومالاً محجوزاً في أخرى.دليلهل تحتاج بلوكتشين أم قاعدة بيانات؟ اختبار من خمسة أسئلةخمسة أسئلة تحدد هل يحتاج مشروعك بلوكتشين، مع تجربة تبني البديل الأرخص في PostgreSQL وتقيس تكلفة العقد الذكي.دليلالتشفير في البلوكتشين: الهاش والمنحنيات والتوقيعاتكيف تصنع المفاتيح والعناوين والتوقيعات في Bitcoin وEthereum، ولماذا يكشف رقم مكرر واحد في التوقيع المفتاح الخاص.دليلكيف يعمل Bitcoin؟ المعاملة والمخرجات غير المنفقة UTXOنبني معاملة Bitcoin بأيدينا ونتتبعها حتى الكتلة، لنفهم لماذا لا يوجد رصيد، وأين تذهب الرسوم، ومتى تصبح الدفعة دفعة فعلاً.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، واختبار التجارب على Docker Engine 29.8.0 مع Python 3.13.16 ومكتبة cryptography 46.0.3، وBitcoin Core v31.1.0 في وضع regtest.