إيثريوم: منصة العقود الذكية والتطبيقات اللامركزية من الجيل التالي

Abstract

Ethereum هو منصة عملة مشفرة وتطبيقات لامركزية من الجيل التالي تقدم blockchain مزودة بلغة برمجة مدمجة كاملة تورنغ (Turing-complete). يتيح ذلك لأي شخص كتابة smart contracts وتطبيقات لامركزية حيث يمكنهم إنشاء قواعدهم الخاصة للملكية وأشكال المعاملات ودوال انتقال الحالة (state transition functions).

الابتكار الجوهري لـ Ethereum هو دمج تقنية blockchain التي ابتكرها Bitcoin مع بيئة برمجة عامة الأغراض. بينما يوفر Bitcoin نظام انتقال حالة بسيط لنقل العملة من حساب إلى آخر، يوفر Ethereum منصة يمكن للمطورين فيها بناء أي نوع من التطبيقات اللامركزية التي يمكنهم تخيلها، من العملات البديلة والأدوات المالية إلى أنظمة تسجيل النطاقات والمنظمات اللامركزية.

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

Introduction and Existing Concepts

إن مفهوم العملة الرقمية اللامركزية، بالإضافة إلى التطبيقات البديلة مثل سجلات الملكية، موجود منذ عقود. قدمت بروتوكولات النقد الإلكتروني المجهولة في الثمانينيات والتسعينيات، التي اعتمدت بشكل رئيسي على بدائية تشفيرية تُعرف باسم Chaumian blinding، عملة بدرجة عالية من الخصوصية، لكن هذه البروتوكولات فشلت إلى حد كبير في اكتساب الزخم بسبب اعتمادها على وسيط مركزي. في عام 1998، أصبح b-money لـ Wei Dai أول اقتراح يقدم فكرة إنشاء المال من خلال حل الألغاز الحسابية بالإضافة إلى الإجماع اللامركزي، لكن الاقتراح كان شحيحاً في التفاصيل حول كيفية تنفيذ الإجماع اللامركزي فعلياً.

في عام 2009، تم تنفيذ عملة لامركزية لأول مرة عملياً بواسطة Satoshi Nakamoto، حيث جمع بين البدائيات المُرسّخة لإدارة الملكية من خلال تشفير public key مع خوارزمية إجماع لتتبع من يملك العملات، تُعرف باسم "proof of work". كانت الآلية وراء proof of work اختراقاً في هذا المجال لأنها حلت مشكلتين في آن واحد. أولاً، قدمت خوارزمية إجماع بسيطة وفعالة بشكل معتدل، تسمح للعقد في الشبكة بالاتفاق جماعياً على مجموعة من التحديثات القانونية لحالة دفتر Bitcoin. ثانياً، قدمت آلية تسمح بالدخول الحر إلى عملية الإجماع، حيث حلت المشكلة السياسية المتعلقة بتحديد من يؤثر على الإجماع، مع منع هجمات sybil في الوقت نفسه.

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

على مدى السنوات الخمس الماضية، كان هناك عدد من المحاولات لتوسيع وظائف Bitcoin. سعت Colored coins لاستخدام blockchain الخاص بـ Bitcoin لتتبع ملكية الأصول البديلة، وحاول Namecoin إنشاء قاعدة بيانات لامركزية لتسجيل الأسماء، واستهدفت بروتوكولات metacoin المتنوعة بناء طبقات إضافية فوق Bitcoin. بينما أظهرت هذه المقاربات وعداً، كانت محدودة في نهاية المطاف بقدرات Bitcoin البرمجية وعدم القدرة على الوصول إلى بيانات blockchain من داخل البرامج النصية.

ما يعتزم Ethereum تقديمه هو blockchain بلغة برمجة Turing-complete مدمجة كاملة الميزات يمكن استخدامها لإنشاء "عقود" يمكنها ترميز دوال state transition عشوائية، مما يسمح للمستخدمين بإنشاء أي من الأنظمة الموصوفة أعلاه، بالإضافة إلى العديد من الأنظمة الأخرى التي لم نتخيلها بعد، ببساطة عن طريق كتابة المنطق في بضعة أسطر من التعليمات البرمجية.

Bitcoin As A State Transition System

من الناحية التقنية، يمكن التفكير في دفتر الحسابات لعملة مشفرة مثل Bitcoin كنظام state transition، حيث يوجد "حالة" تتكون من حالة ملكية جميع عملات bitcoin الموجودة و"دالة state transition" تأخذ حالة ومعاملة وتُخرج حالة جديدة هي النتيجة. في نظام مصرفي قياسي، على سبيل المثال، الحالة هي كشف الرصيد، والمعاملة هي طلب لنقل \(X من A إلى B، ودالة state transition تُنقص القيمة في حساب A بمقدار \)X وتزيد القيمة في حساب B بمقدار \(X. إذا كان حساب A يحتوي على أقل من \)X في المقام الأول، فإن دالة state transition تُرجع خطأ.

"الحالة" في Bitcoin هي مجموعة جميع العملات (تقنياً، "مخرجات المعاملات غير المنفقة" أو UTXO) التي تم سكها ولم تُنفق بعد، حيث يملك كل UTXO فئة ومالكاً (معرف بعنوان 20 بايت وهو في الأساس public key تشفيرية). تحتوي المعاملة على مدخل واحد أو أكثر، يحتوي كل مدخل على إشارة إلى UTXO موجود وتوقيع تشفيري أُنتج بواسطة private key المرتبط بعنوان المالك، ومخرج واحد أو أكثر، يحتوي كل مخرج على UTXO جديد ليُضاف إلى الحالة.

يمكن تعريف دالة state transition APPLY(S,TX) - S' تقريباً كما يلي:

1. لكل مدخل في TX، إذا لم يكن UTXO المُشار إليه موجوداً في S، أرجع خطأ.
2. إذا لم يتطابق التوقيع المُقدم مع مالك UTXO، أرجع خطأ.
3. إذا كان مجموع فئات جميع UTXO المدخلة أقل من مجموع فئات جميع UTXO المُخرجة، أرجع خطأ.
4. أرجع S مع إزالة جميع UTXO المدخلة وإضافة جميع UTXO المُخرجة.

يمنع النصف الأول من الخطوة الأولى مرسلي المعاملات من إنفاق عملات غير موجودة، والنصف الثاني من الخطوة الأولى يمنع مرسلي المعاملات من إنفاق عملات أشخاص آخرين، والخطوة الثانية تفرض حفظ القيمة. لاستخدام هذا للدفع، البروتوكول كالتالي: لنفترض أن Alice تريد إرسال 11.7 BTC إلى Bob. أولاً، ستبحث Alice عن مجموعة من UTXO المتاحة التي تملكها بإجمالي لا يقل عن 11.7 BTC. واقعياً، لن تتمكن Alice من الحصول على 11.7 BTC بالضبط؛ لنقل أن أصغر ما يمكنها الحصول عليه هو 6+4+2=12. ثم تُنشئ معاملة بتلك المدخلات الثلاثة ومخرجين. المخرج الأول سيكون 11.7 BTC بعنوان Bob كمالك، والمخرج الثاني سيكون 0.3 BTC المتبقية كـ "باقي"، بملكية Alice نفسها.

Mining

لو كان لدينا وصول إلى خدمة مركزية موثوقة، لكان تنفيذ هذا النظام بسيطاً؛ يمكن ببساطة برمجته كما هو موصوف، باستخدام القرص الصلب لخادم مركزي لتتبع الحالة. ومع ذلك، مع Bitcoin نحاول بناء نظام عملة لامركزي، لذا سنحتاج إلى دمج نظام state transition مع نظام إجماع لضمان أن الجميع يتفق على ترتيب المعاملات. تتطلب عملية الإجماع اللامركزية في Bitcoin أن تحاول العقد في الشبكة باستمرار إنتاج حزم من المعاملات تُسمى "كتل". تهدف الشبكة إلى إنتاج كتلة واحدة تقريباً كل عشر دقائق، حيث تحتوي كل كتلة على طابع زمني، وnonce، وإشارة إلى (أي hash) الكتلة السابقة وقائمة بجميع المعاملات التي تمت منذ الكتلة السابقة.

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

1. تحقق من أن الكتلة السابقة المُشار إليها بواسطة الكتلة موجودة وصالحة.
2. تحقق من أن الطابع الزمني للكتلة أكبر من الكتلة السابقة وأقل من ساعتين في المستقبل.
3. تحقق من أن proof of work على الكتلة صالح.
4. ليكن S الحالة في نهاية الكتلة السابقة.
5. لنفترض أن TX هي قائمة معاملات الكتلة بـ n معاملة. لكل i في 0...n-1، اضبط S = APPLY(S,TX[i]). إذا أرجع أي تطبيق خطأ، اخرج وأرجع false.
6. أرجع true، وسجل S كالحالة في نهاية هذه الكتلة.

في الأساس، يجب أن توفر كل معاملة في الكتلة انتقال حالة صالحاً مما كانت عليه الحالة القانونية قبل تنفيذ المعاملة إلى حالة جديدة ما. لاحظ أن الحالة ليست مُرمزة في الكتلة بأي شكل؛ هي مجرد تجريد يتذكره عقدة التحقق ولا يمكن حسابها (بأمان) لأي كتلة إلا بالبدء من حالة التكوين وتطبيق كل معاملة في كل كتلة بالتتابع.

يُكافأ المُعدّن على عمله الحسابي بعملات bitcoin جديدة بالإضافة إلى رسوم المعاملات. تعمل عملية التعدين كالتالي: يأخذ المُعدّنون رأس الكتلة ويقومون بتجزئته بشكل متكرر بقيم nonce مختلفة حتى يجدوا hash أقل من هدف صعوبة معين. عندما يجد مُعدّن مثل هذا الـ hash، يبث الكتلة إلى الشبكة، وتتحقق العقد الأخرى من صلاحية الـ hash وصلاحية جميع المعاملات في الكتلة. يتم تعديل هدف الصعوبة تلقائياً بواسطة البروتوكول كل 2016 كتلة (حوالي أسبوعين) لضمان إنتاج الكتل بمعدل ثابت تقريباً.

لاحظ أنه على المدى الطويل، يعتمد أمان blockchain على وجود حافز مالي للمُعدّنين للتصرف بأمانة. إذا سيطر مهاجم على أكثر من 50% من قوة التعدين في الشبكة، فيمكنه تنفيذ "هجوم 51%" بإنشاء blockchain بديل ينمو أسرع من السلسلة الصادقة. ومع ذلك، سيتطلب مثل هذا الهجوم موارد حسابية هائلة ومن المرجح أن تصبح مكافآت تعدين المهاجم عديمة القيمة مع فقدان الشبكة الثقة في سلامة blockchain.

Merkle Trees

أشجار Merkle هي بنية بيانات أساسية تُستخدم في كتل Bitcoin لتمكين التحقق الفعال والآمن من تضمين المعاملات. شجرة Merkle هي شجرة ثنائية من القيم المُجزّأة حيث تحتوي عقد الأوراق على قيم hash للمعاملات الفردية، وتحتوي كل عقدة داخلية على hash لطفليها، وتُبنى بشكل متكرر حتى hash جذر واحد يُخزن في كتلة">رأس الكتلة. تسمح هذه البنية الهرمية لأي شخص بالتحقق من أن معاملة محددة مُدرجة في كتلة عن طريق تنزيل فرع Merkle فقط—سلسلة القيم المُجزّأة من المعاملة حتى الجذر—بدلاً من تنزيل جميع المعاملات في الكتلة.

مكاسب الكفاءة كبيرة: بينما يجب على عقدة Bitcoin كاملة تخزين blockchain بالكامل (حوالي 15 جيجابايت اعتباراً من 2013)، تحتاج عقدة التحقق المبسط من الدفع (SPV) فقط إلى تنزيل رؤوس الكتل التي تحتوي على جذور Merkle، مما يتطلب 4 ميجابايت فقط من البيانات. للتحقق من معاملة، تطلب عقدة SPV فرع Merkle من العقد الكاملة، مما يتطلب بيانات O(log n) فقط حيث n هو عدد المعاملات في الكتلة. هذا التحجيم اللوغاريتمي يجعل من الممكن تشغيل عملاء خفيفي الوزن على الأجهزة المحمولة والبيئات محدودة الموارد.

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

Alternative Blockchain Applications

ألهم نجاح blockchain الخاص بـ Bitcoin محاولات عديدة لتوسيع المفهوم إلى ما هو أبعد من العملة البسيطة. كان Namecoin، الذي أُطلق في عام 2010، من أوائل الأمثلة—قاعدة بيانات لامركزية لتسجيل الأسماء مبنية على blockchain، تسمح للمستخدمين بتسجيل أسماء في نطاق أسماء موزع لا يمكن لأي سلطة مركزية رقابته أو إلغاؤه. ظهرت Colored coins كطريقة لتمثيل أصول بديلة على blockchain الخاص بـ Bitcoin عن طريق "وسم" مخرجات معاملات محددة لتمثيل ملكية أصول حقيقية أو أسهم شركات أو عملات مشفرة أخرى. أضافت Metacoins والبروتوكولات الفوقية مثل Mastercoin (لاحقاً Omni) وظائف إضافية فوق Bitcoin عن طريق ترميز بيانات إضافية في معاملات Bitcoin وبناء قواعد بروتوكول منفصلة فوقها.

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

حفّزت هذه القيود البحث عن منصة blockchain أكثر عمومية. بدلاً من بناء بروتوكول آخر ذو غرض خاص فوق أساس Bitcoin المحدود، يتبنى Ethereum مقاربة مختلفة: توفير blockchain بلغة برمجة Turing-complete مدمجة، تسمح لأي شخص بكتابة smart contracts وتطبيقات لامركزية بقواعد عشوائية للملكية وصيغ المعاملات ودوال state transition.

Scripting

Bitcoin Script، اللغة المستخدمة لتعريف شروط الإنفاق لمعاملات Bitcoin، صُممت عمداً بقيود شديدة. إنها ليست Turing-complete—والأبرز أنها تفتقر إلى الحلقات وبنى تدفق التحكم المعقدة. تعمل اللغة كبيئة تنفيذ بسيطة قائمة على المكدس حيث تقوم العمليات بدفع وسحب القيم، وتقييم الشروط التشفيرية، وتُرجع في النهاية true أو false لتحديد ما إذا كانت المعاملة صالحة. بينما توفر هذه البساطة فوائد أمنية وتسهل التحليل الرسمي، فإنها تجعل العديد من أنواع التطبيقات مستحيلة التنفيذ.

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

تجعل هذه القيود التطبيقات المتطورة مثل المنظمات اللامركزية المستقلة، ومحافظ التوفير بحدود السحب، والبورصات اللامركزية، أو أسواق التنبؤ إما مستحيلة أو تتطلب آليات خارج السلسلة محرجة. قد يتطلب عقد مالي متقدم الوصول إلى بيانات السوق، والقدرة على الحفاظ على حالة داخلية عبر معاملات متعددة، ومنطق شرطي معقد—لا يمكن لـ Bitcoin Script توفير أي منها. يزيل Ethereum هذه القيود بتوفير لغة Turing-complete مع وصول كامل إلى حالة blockchain.

Ethereum

الهدف الأساسي لـ Ethereum هو توفير blockchain بلغة برمجة Turing-complete مدمجة تسمح لأي شخص بكتابة smart contracts وتطبيقات لامركزية حيث يمكنهم إنشاء قواعدهم العشوائية الخاصة للملكية وصيغ المعاملات ودوال state transition. بدلاً من تصميم بروتوكول لتطبيقات محددة مثل العملة أو تسجيل الأسماء أو تداول الأصول، يوفر Ethereum طبقة أساسية—منصة حوسبة موزعة قائمة على blockchain يمكن للمطورين استخدامها لبناء أي تطبيق يمكنهم تخيله.

تختلف البنية جوهرياً عن نموذج UTXO الخاص بـ Bitcoin. يستخدم Ethereum نظاماً قائماً على الحسابات حيث تتكون حالة blockchain من تعيين من العناوين إلى كائنات الحسابات. كل حساب لديه رصيد، وعداد معاملات (nonce)، ولحسابات العقود، كود مرتبط وتخزين. تتضمن المنصة لغة برمجة Turing-complete مدمجة لكتابة كود العقود الذي يُنفذ في Ethereum Virtual Machine (EVM)، وهي بيئة تنفيذ قائمة على المكدس تعالج المعاملات وانتقالات الحالة.

تُمكّن هذه العمومية مجموعة واسعة من التطبيقات: عملات مشفرة بديلة بقواعد إصدار مخصصة، ومشتقات مالية وstablecoins، وأنظمة هوية وسمعة، وتخزين ملفات لامركزي، ومنظمات لامركزية مستقلة (DAOs)، وغير ذلك الكثير. تؤكد الورقة البيضاء أن Ethereum ليس مُحسّناً لأي حالة استخدام معينة بل يوفر اللبنات الأساسية—حسابات ومعاملات ولغة Turing-complete وتنفيذ مقاس بالـ gas—التي يمكن للمطورين دمجها لإنشاء أي تطبيقات يتطلبها النظام البيئي.

Ethereum Accounts

في Ethereum، تتكون الحالة من حسابات، وهناك نوعان أساسيان. الحسابات المملوكة خارجياً (EOAs) تُتحكم بواسطة مفاتيح خاصة وليس لها كود مرتبط—تمثل المستخدمين البشريين أو الكيانات الخارجية التي تتفاعل مع blockchain. حسابات العقود تُتحكم بواسطة كود العقد الخاص بها وتُفعّل عند تلقي رسالة أو معاملة. يتشارك كلا النوعين بنية مشتركة: كل حساب لديه nonce (عداد يُستخدم لضمان أن كل معاملة تُعالج مرة واحدة فقط)، ورصيد ether، وللعقود تحديداً، كود العقد وتخزين دائم.

Ether هي العملة المشفرة الداخلية الأساسية لـ Ethereum، وتعمل كوسيط لنقل القيمة والوحدة الأساسية لدفع رسوم المعاملات (gas). على عكس نموذج UTXO الخاص بـ Bitcoin حيث تتوزع القيمة عبر مخرجات متعددة غير منفقة، تحافظ حسابات Ethereum على رصيد بسيط يزداد عند تلقي ether وينقص عند إرساله. يُبسّط هذا النموذج القائم على الحسابات أنواعاً كثيرة من التطبيقات، خاصة تلك التي تتطلب حالة دائمة أو تحكم وصول معقد، رغم أنه يُقدم اعتبارات أمنية مختلفة مقارنة بمقاربة Bitcoin.

التمييز بين EOAs وحسابات العقود حاسم لفهم عمل Ethereum. يمكن لـ EOAs بدء المعاملات بإنشاء وتوقيع رسائل بمفاتيحها الخاصة، ودفع رسوم gas لتضمين معاملاتها في الكتل. لا تستطيع حسابات العقود بدء المعاملات بنفسها لكن يمكنها إرسال رسائل إلى عقود أخرى استجابة لتلقي معاملة أو رسالة، مما يُمكّن سلاسل تنفيذ معقدة حيث تُطلق معاملة خارجية واحدة تفاعلات متعددة بين العقود.

Messages and Transactions

المعاملات في Ethereum هي حزم بيانات موقعة تُنشأ بواسطة حسابات مملوكة خارجياً وتُبث إلى الشبكة. تحتوي المعاملة على عنوان المستلم، وتوقيع تشفيري يُثبت هوية المرسل، ومقدار ether المُراد تحويله، وحقل بيانات اختياري (حاسم للتفاعل مع العقود)، وSTARTGAS (الحد الأقصى لعدد الخطوات الحسابية المسموح بها للمعاملة)، وGASPRICE (الرسوم لكل خطوة حسابية يرغب المرسل في دفعها). يجمع المُعدّنون هذه المعاملات ويتحققون منها وينفذونها ويضمونها في الكتل، ويتلقون رسوم gas كتعويض.

الرسائل مشابهة مفاهيمياً للمعاملات لكنها تُنتج بواسطة العقود بدلاً من الجهات الخارجية. عندما يُنفذ كود عقد، يمكنه إرسال رسائل إلى عقود أخرى—تحتوي هذه الرسائل الداخلية على المرسل (عنوان العقد)، والمستلم، ومقدار ether المُراد تحويله، وحمولة بيانات اختيارية، وحد STARTGAS. تُمكّن الرسائل التواصل بين العقود، مما يسمح ببناء تطبيقات معقدة من عقود متعددة متفاعلة بدلاً من برامج متجانسة.

آلية gas حاسمة لمنع إساءة الاستخدام: كل خطوة حسابية وعملية تخزين وبايت بيانات في المعاملة تستهلك gas. إذا نفد gas المعاملة قبل اكتمالها، تُعاد جميع تغييرات الحالة (باستثناء دفع gas للمُعدّن)، مما يمنع الحلقات اللانهائية أو الحوسبة المفرطة من تعطيل الشبكة. يُحدد المرسل كلاً من ميزانية gas الإجمالية (STARTGAS) والسعر الذي يرغب في دفعه لكل وحدة (GASPRICE)، ويُسترد أي gas غير مستخدم بعد اكتمال التنفيذ.

Ethereum State Transition Function

تُعرّف دالة state transition في Ethereum APPLY(S,TX) - S' كيف تُحوّل المعاملة حالة blockchain، وتتبع تسلسلاً دقيقاً من الخطوات. أولاً، يتحقق النظام من صلاحية المعاملة: التحقق من صحة التوقيع، وتأكيد أن nonce يتطابق مع nonce حساب المرسل، والتأكد من أن المرسل لديه رصيد كافٍ لدفع التكلفة المسبقة (STARTGAS × GASPRICE بالإضافة إلى القيمة المُرسلة). إذا فشل أي فحص، تُرفض المعاملة قبل بدء التنفيذ. إذا كانت صالحة، تُخصم رسوم المعاملة من حساب المرسل، ويُزاد nonce المرسل، ويُضبط عداد gas أولي على STARTGAS ناقص رسوم لكل بايت من بيانات المعاملة.

بعد ذلك، ينقل النظام قيمة ether المحددة من المرسل إلى المستلم. إذا كان المستلم حساباً مملوكاً خارجياً، يكتمل هذا المعاملة. إذا كان المستلم حساب عقد، يعمل كود العقد في Ethereum Virtual Machine، مستهلكاً gas لكل عملية حتى يكتمل الكود بنجاح، أو يتوقف الكود صراحة، أو ينفد gas. أثناء التنفيذ، يمكن للعقد قراءة وتعديل تخزينه، وإرسال رسائل إلى عقود أخرى، وإنشاء عقود جديدة.

أخيراً، إذا فشل نقل القيمة (رصيد غير كافٍ) أو فشل تنفيذ الكود (نفاد gas أو حدوث خطأ)، تُعاد جميع تغييرات الحالة—لكن المرسل لا يزال يدفع رسوم gas للمُعدّن عن الحوسبة المُنجزة. إذا نجح التنفيذ، يُسترد gas المتبقي إلى المرسل، ويُرسل gas المُستهلك إلى المُعدّن كرسوم. تضمن هذه الآلية تعويض المُعدّنين عن الحوسبة مع منع التنفيذ الجامح من استهلاك موارد غير محدودة.

Code Execution

آلة Ethereum الافتراضية (EVM) هي بيئة التشغيل حيث يُنفذ كود العقد—آلة افتراضية منخفضة المستوى قائمة على المكدس، مشابهة مفاهيمياً لآلة Java الافتراضية أو WebAssembly. يُخزن كود العقد كتسلسل من البايتات، حيث يمثل كل بايت عملية (opcode) يمكن لـ EVM تنفيذها. نموذج التنفيذ بسيط وحتمي عمداً: يجب أن تصل كل عقدة تشغل EVM بنفس حالة الإدخال والمعاملة إلى نفس حالة الإخراج، مما يضمن الإجماع عبر الشبكة.

يوفر EVM ثلاثة أنواع مميزة من التخزين للحوسبة. المكدس هو بنية "آخر من يدخل أول من يخرج" (LIFO) محدودة بـ 1024 عنصراً، تُستخدم لقيم العمليات الفورية. الذاكرة هي مصفوفة بايت قابلة للتوسع لانهائياً تستمر فقط خلال استدعاء رسالة واحدة وتُعاد تهيئتها بين عمليات التنفيذ. التخزين هو مخزن key-value دائم مرتبط بشكل دائم بكل حساب عقد، حيث تحافظ العقود على حالتها طويلة المدى عبر المعاملات. تُسعّر أنواع التخزين هذه بشكل مختلف في gas—عمليات المكدس والذاكرة رخيصة، بينما عمليات التخزين مكلفة لمنع تضخم blockchain.

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

Blockchain and Mining

blockchain الخاص بـ Ethereum مشابه جوهرياً لـ Bitcoin، حيث يعمل كقاعدة بيانات تحتوي على كل معاملة تم تنفيذها. ومع ذلك، بينما يُخزن Bitcoin قائمة المعاملات فقط، يُخزن Ethereum كلاً من قائمة المعاملات والحالة الأحدث. كل كتلة في Ethereum تحتوي على hash الكتلة السابقة، وجذر الحالة (hash الجذر لـ Merkle Patricia trie الذي يمثل الحالة الكاملة)، وجذر المعاملات، وجذر الإيصالات (يُخزن بيانات من تنفيذ المعاملات)، بالإضافة إلى قيم الصعوبة والطابع الزمني وnonce. الحالة نفسها هي Merkle Patricia trie كبير يُعيّن العناوين إلى كائنات الحسابات، حيث كل حساب لديه رصيد وnonce وكود (إن وُجد) وتخزين.

يستخدم Ethereum نسخة معدلة من بروتوكول GHOST (الشجرة الفرعية الأثقل المرصودة بجشع) لمعالجة مشاكل الأمان الناشئة عن أوقات الكتل السريعة. في بروتوكولات السلسلة الأطول التقليدية، تؤدي الكتل السريعة إلى معدلات عالية من الكتل القديمة، مما يقلل أمان الشبكة ويزيد مخاطر المركزية لأن المُعدّنين الكبار يُهدرون حوسبة أقل على الكتل القديمة. يُضمّن GHOST الكتل القديمة (تُسمى "أعمام" في Ethereum) في حساب أي سلسلة هي الأطول، ويوفر مكافآت جزئية لكتل الأعمام، محفزاً المُعدّنين على الإشارة إليها. يسمح هذا لـ Ethereum بالحفاظ على وقت كتلة مستهدف يبلغ حوالي 12 ثانية مع الحفاظ على أمان الشبكة.

تعمل خوارزمية التعدين بشكل مشابه لـ proof-of-work الخاص بـ Bitcoin، مما يتطلب من المُعدّنين إيجاد nonce بحيث يكون hash الكتلة أقل من هدف صعوبة معين. ومع ذلك، فإن خوارزمية التعدين كثيفة الذاكرة في Ethereum (Ethash) مصممة لتكون مقاومة لـ ASIC، مما يُعزز نظام تعدين أكثر لامركزية. تتكيف الصعوبة ديناميكياً بناءً على أوقات الكتل للحفاظ على هدف ~12 ثانية، مما يضمن إنتاج كتل متسق بينما يوفر بروتوكول GHOST ضمانات أمنية رغم أوقات الكتل الأسرع مقارنة بمتوسط Bitcoin البالغ 10 دقائق.

Applications

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

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

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

Token Systems

أنظمة الرموز بسيطة بشكل مدهش في التنفيذ على Ethereum، رغم كونها واحدة من أقوى وأكثر التطبيقات شيوعاً. في جوهرها، أنظمة الرموز هي ببساطة قاعدة بيانات بعملية واحدة: طرح X وحدة من الحساب A وإضافة X وحدة إلى الحساب B، بشرط أن A كان لديه على الأقل X وحدة قبل المعاملة وأن المعاملة مُصرح بها من A. يتطلب التنفيذ الحفاظ على تعيين من العناوين إلى الأرصدة وتوفير دالة نقل تُجري الفحوصات المناسبة قبل نقل الرموز بين الحسابات.

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

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

Financial Derivatives and Stable-Value Currencies

تمثل المشتقات المالية أحد أكثر التطبيقات أساسية وأهمية لعقود Ethereum الذكية. يوضح عقد تحوط بسيط الآلية الأساسية: يودع الطرف A مبلغاً معيناً من ether بقيمة \(1000، ويودع الطرف B مبلغاً مكافئاً، ويسجل العقد قيمة ether بالدولار في تلك اللحظة باستخدام تغذية بيانات. بعد 30 يوماً، يعيد العقد حساب القيمة ويرسل ether بقيمة \)1000 إلى A والباقي إلى B. إذا ارتفع سعر ether، يتلقى A ether أقل لكنه يحافظ على قيمة $1000؛ وإذا انخفض، يتلقى A المزيد من ether للحفاظ على تلك القيمة. يسمح هذا لـ A بالتحوط ضد التقلبات بينما يضارب B على تحركات الأسعار.

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

يمكن بناء Stablecoins وأدوات مالية أكثر تعقيداً باستخدام آليات مماثلة. قد يحافظ عقد stablecoin على احتياطي من ether ويُصدر رموزاً مرتبطة بعملة ورقية، معدلاً تلقائياً العرض أو متطلبات الضمان بناءً على تغذيات الأسعار. عقود الخيارات والعقود الآجلة والمبادلات والمشتقات الأخرى التي تتطلب عادةً أطراً قانونية معقدة ووسطاء موثوقين يمكن بدلاً من ذلك ترميزها كعقود ذكية ذاتية التنفيذ. تُمكّن بنية التمويل القابلة للبرمجة هذه هندسة مالية متطورة مع الحفاظ على ضمانات الشفافية والأمان لتقنية blockchain.

Identity and Reputation Systems

نظام تسجيل الأسماء المشابه لـ Namecoin قابل للتنفيذ بسهولة على Ethereum ويُعد أبسط مثال على نظام هوية. يحافظ العقد على قاعدة بيانات بجدول key-value يُعيّن الأسماء إلى البيانات المرتبطة (مثل عناوين IP أو المفاتيح العامة أو معلومات أخرى). يمكن لأي شخص تسجيل اسم بإرسال معاملة إلى العقد مع رسوم تسجيل صغيرة، بشرط ألا يكون الاسم مأخوذاً بالفعل. يمكن للمالك تحديث البيانات المرتبطة في أي وقت، ويمكن جعل الأسماء قابلة للنقل أو دائمة وفقاً للقواعد المُرمزة في العقد.

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

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

Decentralized File Storage

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

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

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

Decentralized Autonomous Organizations

المنظمة اللامركزية المستقلة (DAO) هي كيان افتراضي لديه مجموعة من الأعضاء أو المساهمين الذين يملكون جماعياً الحق في إنفاق أموال الكيان وتعديل كوده. تعمل DAO نموذجية بقاعدة بسيطة: يُحتاج 67% من الأعضاء لاتخاذ قرارات الإنفاق أو تعديل كود المنظمة. يمكن للأعضاء تقديم مقترحات والتصويت عليها، وإذا حصل مقترح على دعم كافٍ، ينفذ العقد القرار تلقائياً. يمكن أن تكون حصص العضوية قابلة للنقل، مما يسمح بسوق سائلة لمشاركة DAO، ويمكن أن يكون لفئات مختلفة من الحصص حقوق تصويت أو مطالبات اقتصادية مختلفة.

أبسط تصميم DAO هو عقد ذاتي التعديل يحافظ على قائمة بالأعضاء ويتطلب تصويت أغلبية 2/3 لتغيير أي جانب من العقد، بما في ذلك قواعد التصويت الخاصة به. سيقدم الأعضاء تغييرات الكود كمعاملات، وسيصوت أعضاء آخرون، وعند الوصول إلى العتبة، سيُحدث العقد نفسه. قد تتضمن التصاميم الأكثر تطوراً أنظمة تصويت مُفوضة حيث يمكن للأعضاء تخصيص قوتهم التصويتية لممثلين، أو ديمقراطية سائلة حيث يمكن تفويض الأصوات ولكن استرجاعها في أي وقت للقرارات المهمة.

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

Further Applications

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

تسمح أسواق التنبؤ على السلسلة للمستخدمين بالمراهنة على أحداث مستقبلية، مما يُنشئ آليات تنبؤ قوية من خلال حكمة الجماهير. يمكن تعزيزها ببروتوكولات على غرار SchellingCoin لإنشاء oracles لامركزية: يُبلّغ المشاركون بشكل مستقل عن البيانات (مثل نتائج الانتخابات أو أحوال الطقس)، ويتلقى من تتطابق تقاريرهم مع الأغلبية مكافآت بينما يُعاقب المنحرفون. يُحفز هذا النهج الاقتصادي التشفيري الإبلاغ الصادق ويمكن أن يوفر بيانات العالم الحقيقي الموثوقة لعقود أخرى دون الحاجة إلى الثقة في أي مزود oracle واحد.

تمثل محافظ التوقيع المتعدد تطبيقاً مهماً آخر، مما يُمكّن من التحكم المشترك في الأموال بين أطراف متعددة. قد تتطلب محفظة multi-sig بنمط 2-of-3 موافقة أي طرفين من ثلاثة أطراف معينة على المعاملة قبل إنفاق الأموال، وهو مفيد لترتيبات الضمان أو خزائن الشركات أو الأمان الشخصي. يمكن للأسواق اللامركزية أن تجمع بين أنظمة الهوية ودرجات السمعة وعقود الضمان وآليات حل النزاعات لتمكين التجارة من نظير إلى نظير دون منصات مركزية. يُظهر كل من هذه التطبيقات كيف تُمكّن قابلية Ethereum للبرمجة نماذج ثقة وهياكل تنظيمية جديدة.

Miscellanea And Concerns

يتضمن تنفيذ Ethereum لبروتوكول GHOST المُعدل قواعد محددة لتضمين الأعمام والمكافآت. يجب أن يكون الأعمام أبناء مباشرين لسلف الكتلة الحالية (بين 2 و7 أجيال للخلف)، ويجب أن يكونوا رؤوس كتل صالحة، ويجب أن يكونوا متميزين عن الأعمام السابقين، ويجب ألا يكونوا أسلافاً مباشرين للكتلة الحالية. تتلقى كتل الأعمام 87.5% من مكافأة الكتلة القياسية، بينما تتلقى الكتلة المُضمّنة 3.125% إضافية لكل عم مُضمّن (حتى عمين). يُشجع هيكل الحوافز هذا المُعدّنين على الإشارة إلى الكتل القديمة التي يلاحظونها، مما يُعزز أمان الشبكة مع مكافأة المُعدّنين الذين عانوا من سوء حظ مؤقت في انتشار الشبكة.

يعتمد نظام الرسوم على مفهوم "gas"، حيث لكل عملية حسابية تكلفة gas ثابتة. على سبيل المثال، تكلف عملية الضرب 5 gas، وتكلف تجزئة SHA256 عشرين gas، ولكل معاملة تكلفة أساسية قدرها 21,000 gas. يُحدد المستخدمون كلاً من حد gas (الحد الأقصى لـ gas الذي يرغبون في استهلاكه) وسعر gas (كم من ether سيدفعون لكل وحدة gas). يخدم هذا النظام أغراضاً متعددة: يمنع الحلقات اللانهائية وهجمات حجب الخدمة بضمان أن كل حوسبة مدفوعة، ويُنشئ سوقاً لمساحة الكتلة حيث يتزايد المستخدمون عبر أسعار gas، ويسمح للمُعدّنين بتحديد حد أدنى لسعر gas يقبلونه، حامياً موارد الشبكة.

تبقى قابلية التوسع مصدر قلق كبير، حيث يجب على كل عقدة كاملة معالجة كل معاملة للتحقق من الحالة. تُعاني بنى blockchain الحالية لمطابقة إنتاجية المعاملات في الأنظمة المركزية. تشمل الحلول المحتملة تجزئة الحالة، حيث تُعالج عقد مختلفة مجموعات فرعية مختلفة من المعاملات، والانتقال من proof-of-work إلى إجماع proof-of-stake، الذي يمكن أن يُمكّن إنتاج كتل أكثر كفاءة. يمكن للعملاء الخفيفين الذين يستخدمون إثباتات Merkle التحقق من المعاملات دون معالجة جميع الكتل، لكن يجب أن يُعالج شخص ما كل شيء. تمثل تحديات قابلية التوسع هذه مجالات نشطة للبحث والتطوير حاسمة لجدوى Ethereum على المدى الطويل.

Conclusion

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

بدلاً من توفير مجموعة محدودة من العمليات المصممة لحالات استخدام محددة، يوفر Ethereum لغة برمجة Turing-complete تُمكّن المطورين من بناء أي تطبيق يمكنهم تصميمه. تريد اختراع مشتق مالي خاص بك؟ إنشاء عملتك الخاصة؟ إنشاء حكومة على blockchain؟ كل هذا قابل للتنفيذ بسهولة مع نظام Ethereum البرمجي. قوة المنصة لا تكمن في التنبؤ بالتطبيقات التي ستُبنى، بل في توفير البنية التحتية الأساسية التي تجعل بناءها سهلاً.

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

References and Further Reading

تستند ورقة Ethereum البيضاء إلى أعمال سابقة واسعة في أبحاث العملات المشفرة والأنظمة الموزعة. يُوصف بروتوكول Bitcoin الأساسي في ورقة Satoshi Nakamoto الأصلية لعام 2008 "Bitcoin: A Peer-to-Peer Electronic Cash System"، التي قدمت مفهوم العملة الرقمية القائمة على blockchain. تشمل المحاولات المبكرة لتوسيع وظائف Bitcoin نظام Namecoin، وهو نظام تسجيل أسماء لامركزي يُظهر تطبيقات blockchain خارج نطاق العملة، رغم تقييده بقدرات Bitcoin البرمجية المحدودة.

اقترحت ورقة Colored coins البيضاء طريقة لتمثيل أصول بديلة على blockchain الخاص بـ Bitcoin عن طريق "تلوين" عملات bitcoin محددة لتمثيل أصول أخرى، بينما حاول Mastercoin إنشاء طبقة بروتوكول فوق Bitcoin لأدوات مالية أكثر تعقيداً. أبرز كلاهما قيود البناء على Bitcoin وحفّز الحاجة إلى منصة أكثر مرونة. وفّر مفهوم الشركات اللامركزية المستقلة، المُستكشف في Bitcoin Magazine، أسساً نظرية للحوكمة التنظيمية من خلال العقود الذكية.

تشمل المكونات التقنية الرئيسية التحقق المبسط من الدفع (SPV) للعملاء الخفيفين، وأشجار Merkle للتحقق الفعال من البيانات، وأشجار Patricia لتمثيل حالة Ethereum. يُعالج بروتوكول GHOST (الشجرة الفرعية الأثقل المرصودة بجشع)، المُوصف في ورقة تشفير عام 2013، مشاكل الأمان الناشئة عن أوقات الكتل السريعة ويُشكل أساس آلية إجماع Ethereum. تمثل هذه المراجع الأسس الفكرية التي بُني عليها Ethereum، حيث تجمع رؤى من العملات المشفرة والأنظمة الموزعة والتشفير ونظرية الألعاب لإنشاء منصة blockchain عامة الغرض.