الورقة البيضاء لإيثيريوم

على الرغم من مرور عدة سنوات، فإننا نحتفظ بالورقة الأصلية أدناه لأنها لا تزال بمثابة مرجع مفيد وتمثيل دقيق لـ إيثيريوم ورؤيتها.

منصة عقود ذكية وتطبيقات لامركزية (dapp) من الجيل القادم

غالبًا ما يُشاد بتطوير ساتوشي ناكاموتو لعملة بيتكوين في عام 2009 باعتباره تطورًا جذريًا في مجال المال والعملات، لكونه المثال الأول على أصل رقمي ليس له غطاء أو "قيمة جوهرية (opens in a new tab)" ولا مُصدر أو مُتحكم مركزي في نفس الوقت. ومع ذلك، هناك جزء آخر من تجربة بيتكوين، والذي يمكن القول إنه أكثر أهمية، وهو تقنية سلسلة الكتل الأساسية كأداة للإجماع الموزع، وبدأ الاهتمام يتحول بسرعة إلى هذا الجانب الآخر من بيتكوين. تشمل التطبيقات البديلة الشائعة لتقنية سلسلة الكتل استخدام أصول رقمية على سلسلة الكتل لتمثيل عملات وأدوات مالية مخصصة ("العملات الملونة (opens in a new tab)")، وملكية جهاز مادي أساسي ("الملكية الذكية (opens in a new tab)")، والأصول غير القابلة للاستبدال مثل أسماء النطاقات ("Namecoin (opens in a new tab)")، بالإضافة إلى تطبيقات أكثر تعقيدًا تتضمن تحكمًا مباشرًا في الأصول الرقمية بواسطة جزء من التعليمات البرمجية التي تنفذ قواعد عشوائية ("عقود ذكية (opens in a new tab)") أو حتى "منظمات مستقلة لامركزية (opens in a new tab)" (DAOs) قائمة على سلسلة الكتل. ما تعتزم إيثيريوم تقديمه هو سلسلة كتل مزودة بلغة برمجة مدمجة كاملة ومكتملة تورنغ يمكن استخدامها لإنشاء "عقود" يمكن استخدامها لتشفير دوال انتقال حالة عشوائية، مما يسمح للمستخدمين بإنشاء أي من الأنظمة الموضحة أعلاه، بالإضافة إلى العديد من الأنظمة الأخرى التي لم نتخيلها بعد، ببساطة عن طريق كتابة المنطق في بضعة أسطر من التعليمات البرمجية.

مقدمة عن بيتكوين والمفاهيم الحالية

التاريخ

كان مفهوم العملة الرقمية اللامركزية، بالإضافة إلى التطبيقات البديلة مثل سجلات الملكية، موجودًا منذ عقود. وفرت بروتوكولات النقد الإلكتروني المجهولة في الثمانينيات والتسعينيات، والتي اعتمدت في الغالب على أساسيات علم التشفير المعروفة باسم التعمية الشومية (Chaumian blinding)، عملة بدرجة عالية من الخصوصية، لكن البروتوكولات فشلت إلى حد كبير في اكتساب الزخم بسبب اعتمادها على وسيط مركزي. في عام 1998، أصبح مقترح b-money (opens in a new tab) الذي قدمه وي داي أول مقترح يقدم فكرة إنشاء الأموال من خلال حل الألغاز الحسابية بالإضافة إلى الإجماع اللامركزي، لكن المقترح كان يفتقر إلى التفاصيل حول كيفية تنفيذ الإجماع اللامركزي فعليًا. في عام 2005، قدم هال فيني مفهوم "إثباتات العمل القابلة لإعادة الاستخدام (opens in a new tab)"، وهو نظام يستخدم أفكارًا من b-money جنبًا إلى جنب مع ألغاز Hashcash الصعبة حسابيًا لآدم باك لإنشاء مفهوم لعملة مشفرة، ولكنه مرة أخرى لم يرقَ إلى المستوى المثالي من خلال الاعتماد على الحوسبة الموثوقة كخلفية. في عام 2009، تم تنفيذ عملة لامركزية لأول مرة عمليًا بواسطة ساتوشي ناكاموتو، حيث جمعت بين الأساسيات الراسخة لإدارة الملكية من خلال تشفير المفتاح العام مع خوارزمية إجماع لتتبع من يملك العملات، والمعروفة باسم "إثبات العمل (PoW)".

كانت الآلية الكامنة وراء إثبات العمل (PoW) بمثابة اختراق في هذا المجال لأنها حلت مشكلتين في وقت واحد. أولاً، وفرت خوارزمية إجماع بسيطة وفعالة بشكل معتدل، مما سمح للعقد في الشبكة بالاتفاق بشكل جماعي على مجموعة من التحديثات الأساسية لحالة دفتر أستاذ بيتكوين. ثانيًا، وفرت آلية للسماح بالدخول الحر إلى عملية الإجماع، مما أدى إلى حل المشكلة السياسية المتمثلة في تحديد من يحق له التأثير على الإجماع، مع منع هجمات سيبيل (sybil attacks) في نفس الوقت. وتقوم بذلك عن طريق استبدال حاجز رسمي للمشاركة، مثل اشتراط التسجيل ككيان فريد في قائمة معينة، بحاجز اقتصادي - حيث يتناسب وزن العقدة الواحدة في عملية التصويت على الإجماع طرديًا مع قوة الحوسبة التي توفرها العقدة. منذ ذلك الحين، تم اقتراح نهج بديل يسمى إثبات الحصة (PoS)، والذي يحسب وزن العقدة على أنه متناسب مع ممتلكاتها من العملات وليس الموارد الحسابية؛ وتتجاوز مناقشة المزايا النسبية للنهجين نطاق هذه الورقة البيضاء ولكن تجدر الإشارة إلى أنه يمكن استخدام كلا النهجين ليكون بمثابة العمود الفقري لأي عملة مشفرة.

بيتكوين كنظام انتقال للحالة

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

APPLY(S,TX) -> S' or ERROR

في النظام المصرفي المحدد أعلاه:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

لكن:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

إن "الحالة" في بيتكوين هي مجموعة من جميع العملات (من الناحية الفنية، "مخرجات المعاملات غير المنفقة" أو UTXO) التي تم سكها ولم يتم إنفاقها بعد، حيث يكون لكل UTXO فئة ومالك (محدد بواسطة عنوان بحجم 20-byte وهو في الأساس مفتاح عام تشفيري^fn1). تحتوي المعاملة على مدخل واحد أو أكثر، حيث يحتوي كل مدخل على إشارة إلى UTXO موجود وتوقيع تشفيري تم إنتاجه بواسطة المفتاح الخاص المرتبط بعنوان المالك، ومخرج واحد أو أكثر، حيث يحتوي كل مخرج على UTXO جديد ليتم إضافته إلى الحالة.

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

1. لكل مدخل في TX:

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

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

التعدين

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

الخوارزمية للتحقق مما إذا كانت الكتلة صالحة، معبرًا عنها في هذا النموذج، هي كما يلي:

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

بشكل أساسي، يجب أن توفر كل معاملة في الكتلة انتقالًا صالحًا للحالة من الحالة الأساسية قبل تنفيذ المعاملة إلى حالة جديدة ما. لاحظ أن الحالة غير مشفرة في الكتلة بأي شكل من الأشكال؛ إنها مجرد تجريد يجب أن تتذكره العقدة المدققة ولا يمكن حسابه (بشكل آمن) لأي كتلة إلا من خلال البدء من حالة التكوين (genesis state) وتطبيق كل معاملة في كل كتلة بالتسلسل. بالإضافة إلى ذلك، لاحظ أن الترتيب الذي يُدرج به المُعَدِّن المعاملات في الكتلة مهم؛ إذا كان هناك معاملتان A و B في كتلة بحيث تنفق B مخرج UTXO تم إنشاؤه بواسطة A، فستكون الكتلة صالحة إذا جاءت A قبل B ولكن ليس العكس.

شرط الصلاحية الوحيد الموجود في القائمة أعلاه والذي لا يوجد في الأنظمة الأخرى هو اشتراط "إثبات العمل (PoW)". الشرط الدقيق هو أن تجزئة double-SHA256 لكل كتلة، والتي يتم التعامل معها كرقم 256-bit، يجب أن تكون أقل من هدف يتم تعديله ديناميكيًا، والذي يبلغ وقت كتابة هذا التقرير حوالي 2¹⁸⁷. الغرض من ذلك هو جعل إنشاء الكتلة "صعبًا" من الناحية الحسابية، وبالتالي منع مهاجمي سيبيل من إعادة إنشاء سلسلة الكتل بأكملها لصالحهم. نظرًا لأن SHA256 مصمم ليكون دالة شبه عشوائية لا يمكن التنبؤ بها تمامًا، فإن الطريقة الوحيدة لإنشاء كتلة صالحة هي ببساطة التجربة والخطأ، وزيادة الرقم الفريد (nonce) بشكل متكرر ومعرفة ما إذا كانت التجزئة الجديدة تتطابق.

عند الهدف الحالي البالغ ~2¹⁸⁷، يجب أن تقوم الشبكة بمتوسط ~2⁶⁹ محاولة قبل العثور على كتلة صالحة؛ بشكل عام، يتم إعادة معايرة الهدف بواسطة الشبكة كل 2016 كتلة بحيث يتم إنتاج كتلة جديدة في المتوسط بواسطة عقدة ما في الشبكة كل عشر دقائق. من أجل تعويض المُعَدِّنين عن هذا العمل الحسابي، يحق لمُعَدِّن كل كتلة تضمين معاملة تمنح نفسه 25 BTC من العدم. بالإضافة إلى ذلك، إذا كان لأي معاملة إجمالي فئة أعلى في مدخلاتها مقارنة بمخرجاتها، فإن الفرق يذهب أيضًا إلى المُعَدِّن كـ "رسوم المعاملة". بالمناسبة، هذه هي أيضًا الآلية الوحيدة التي يتم من خلالها الإصدار لعملات BTC؛ لم تحتوِ حالة التكوين على أي عملات على الإطلاق.

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

1. إرسال 100 BTC إلى تاجر مقابل منتج ما (يفضل أن يكون سلعة رقمية سريعة التسليم)
2. انتظار تسليم المنتج
3. إنتاج معاملة أخرى ترسل نفس الـ 100 BTC لنفسه
4. محاولة إقناع الشبكة بأن معاملته لنفسه هي التي جاءت أولاً.

بمجرد حدوث الخطوة (1)، بعد بضع دقائق سيقوم مُعَدِّن ما بتضمين المعاملة في كتلة، لنقل الكتلة رقم 270000. بعد حوالي ساعة، ستتم إضافة خمس كتل أخرى إلى السلسلة بعد تلك الكتلة، حيث تشير كل من هذه الكتل بشكل غير مباشر إلى المعاملة وبالتالي "تؤكدها". في هذه المرحلة، سيقبل التاجر الدفع كدفع نهائي ويسلم المنتج؛ وبما أننا نفترض أن هذه سلعة رقمية، فإن التسليم يكون فوريًا. الآن، يقوم المهاجم بإنشاء معاملة أخرى ترسل الـ 100 BTC لنفسه. إذا قام المهاجم ببساطة بإطلاقها في الشبكة الفعلية، فلن تتم معالجة المعاملة؛ سيحاول المُعَدِّنون تشغيل APPLY(S,TX) ويلاحظون أن TX تستهلك UTXO لم يعد موجودًا في الحالة. لذلك بدلاً من ذلك، يقوم المهاجم بإنشاء "تفرع" لسلسلة الكتل، بدءًا من تعدين إصدار آخر من الكتلة 270000 يشير إلى نفس الكتلة 269999 كأصل ولكن مع المعاملة الجديدة بدلاً من القديمة. نظرًا لأن بيانات الكتلة مختلفة، فإن هذا يتطلب إعادة إثبات العمل (PoW). علاوة على ذلك، فإن الإصدار الجديد للمهاجم من الكتلة 270000 له تجزئة مختلفة، لذلك فإن الكتل الأصلية من 270001 إلى 270005 لا "تشير" إليها؛ وبالتالي، فإن السلسلة الأصلية والسلسلة الجديدة للمهاجم منفصلتان تمامًا. القاعدة هي أنه في أي تفرع، يتم اعتبار سلسلة الكتل الأطول هي الحقيقة، ولذا سيعمل المُعَدِّنون الشرعيون على سلسلة 270005 بينما يعمل المهاجم وحده على سلسلة 270000. لكي يجعل المهاجم سلسلة الكتل الخاصة به هي الأطول، سيحتاج إلى قوة حسابية أكبر من بقية الشبكة مجتمعة من أجل اللحاق بالركب (ومن هنا جاء مصطلح "هجوم 51%").

أشجار ميركل

اليسار: يكفي تقديم عدد صغير فقط من العقد في شجرة ميركل لتقديم إثبات على صحة الفرع.

اليمين: أي محاولة لتغيير أي جزء من شجرة ميركل ستؤدي في النهاية إلى عدم اتساق في مكان ما أعلى السلسلة.

من ميزات قابلية التوسع المهمة في بيتكوين أن الكتلة يتم تخزينها في بنية بيانات متعددة المستويات. إن "تجزئة" الكتلة هي في الواقع فقط تجزئة رأس الكتلة، وهي قطعة من البيانات بحجم 200-byte تقريبًا تحتوي على الطابع الزمني، والرقم الفريد (nonce)، وتجزئة الكتلة السابقة، وتجزئة الجذر لبنية بيانات تسمى شجرة ميركل تخزن جميع المعاملات في الكتلة. شجرة ميركل هي نوع من الأشجار الثنائية، تتكون من مجموعة من العقد مع عدد كبير من العقد الطرفية (leaf nodes) في أسفل الشجرة تحتوي على البيانات الأساسية، ومجموعة من العقد الوسيطة حيث تكون كل عقدة هي تجزئة لطفليها، وأخيرًا عقدة جذر واحدة، تتشكل أيضًا من تجزئة طفليها، وتمثل "قمة" الشجرة. الغرض من شجرة ميركل هو السماح بتسليم البيانات الموجودة في الكتلة بشكل مجزأ: يمكن للعقدة تنزيل رأس الكتلة فقط من مصدر واحد، والجزء الصغير من الشجرة ذي الصلة بها من مصدر آخر، مع الاستمرار في التأكد من صحة جميع البيانات. السبب في نجاح ذلك هو أن التجزئات تنتشر لأعلى: إذا حاول مستخدم خبيث تبديل معاملة مزيفة في أسفل شجرة ميركل، فإن هذا التغيير سيؤدي إلى تغيير في العقدة الموجودة أعلاه، ثم تغيير في العقدة الموجودة فوقها، مما يؤدي في النهاية إلى تغيير جذر الشجرة وبالتالي تجزئة الكتلة، مما يتسبب في قيام البروتوكول بتسجيلها ككتلة مختلفة تمامًا (من المؤكد تقريبًا أنها تحتوي على إثبات عمل غير صالح).

يمكن القول إن بروتوكول شجرة ميركل ضروري للاستدامة على المدى الطويل. تشغل "عقدة كاملة" في شبكة بيتكوين، وهي العقدة التي تخزن وتعالج كل كتلة بالكامل، حوالي 15 GB من مساحة القرص في شبكة بيتكوين اعتبارًا من أبريل 2014، وتنمو بأكثر من جيجابايت شهريًا. حاليًا، هذا قابل للتطبيق على بعض أجهزة الكمبيوتر المكتبية وليس الهواتف، وفي المستقبل لاحقًا لن يتمكن من المشاركة سوى الشركات والهواة. يسمح بروتوكول يُعرف باسم "التحقق المبسط من الدفع" (SPV) بوجود فئة أخرى من العقد، تسمى "عقدة خفيفة" (light nodes)، والتي تقوم بتنزيل رؤوس الكتل، والتحقق من إثبات العمل (PoW) على رؤوس الكتل، ثم تنزيل "الفروع" المرتبطة بالمعاملات ذات الصلة بها فقط. يتيح ذلك للعقد الخفيفة تحديد حالة أي معاملة بيتكوين، ورصيدها الحالي، بضمان قوي للأمان مع تنزيل جزء صغير جدًا فقط من سلسلة الكتل بأكملها.

تطبيقات سلسلة الكتل البديلة

إن فكرة أخذ فكرة سلسلة الكتل الأساسية وتطبيقها على مفاهيم أخرى لها أيضًا تاريخ طويل. في عام 2005، خرج نيك سابو بمفهوم "سندات الملكية الآمنة مع سلطة المالك (opens in a new tab)"، وهي وثيقة تصف كيف ستسمح "التطورات الجديدة في تكنولوجيا قواعد البيانات المنسوخة" بنظام قائم على سلسلة الكتل لتخزين سجل لمن يملك أي أرض، مما يخلق إطارًا متقنًا يتضمن مفاهيم مثل الاستيطان، والحيازة السلبية، وضريبة الأراضي الجورجية. ومع ذلك، للأسف لم يكن هناك نظام فعال لقواعد البيانات المنسوخة متاحًا في ذلك الوقت، ولذا لم يتم تنفيذ البروتوكول عمليًا أبدًا. ولكن بعد عام 2009، بمجرد تطوير الإجماع اللامركزي لبيتكوين، بدأ عدد من التطبيقات البديلة في الظهور بسرعة.

• Namecoin - تم إنشاؤه في عام 2010، وأفضل وصف لـ Namecoin (opens in a new tab) هو أنه قاعدة بيانات لامركزية لتسجيل الأسماء. في البروتوكولات اللامركزية مثل Tor وبيتكوين وBitMessage، يجب أن تكون هناك طريقة ما لتحديد الحسابات حتى يتمكن الأشخاص الآخرون من التفاعل معها، ولكن في جميع الحلول الحالية، النوع الوحيد المتاح من المعرفات هو تجزئة شبه عشوائية مثل 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy. من الناحية المثالية، يرغب المرء في أن يكون قادرًا على امتلاك حساب باسم مثل "george". ومع ذلك، تكمن المشكلة في أنه إذا تمكن شخص واحد من إنشاء حساب باسم "george"، فيمكن لشخص آخر استخدام نفس العملية لتسجيل "george" لنفسه أيضًا وانتحال شخصيته. الحل الوحيد هو نموذج الأسبقية في التسجيل، حيث ينجح المسجل الأول ويفشل الثاني - وهي مشكلة مناسبة تمامًا لبروتوكول إجماع بيتكوين. يعد Namecoin أقدم وأنجح تنفيذ لنظام تسجيل الأسماء باستخدام مثل هذه الفكرة.
• العملات الملونة (Colored coins) - الغرض من العملات الملونة (opens in a new tab) هو العمل كبروتوكول للسماح للأشخاص بإنشاء عملاتهم الرقمية الخاصة - أو، في الحالة البسيطة والمهمة لعملة ذات وحدة واحدة، رموز مميزة رقمية، على سلسلة كتل بيتكوين. في بروتوكول العملات الملونة، يقوم المرء بـ "الإصدار" لعملة جديدة عن طريق تعيين لون علنًا لـ UTXO معين في بيتكوين، ويحدد البروتوكول بشكل متكرر لون UTXO الأخرى ليكون نفس لون المدخلات التي أنفقتها المعاملة التي أنشأتها (تنطبق بعض القواعد الخاصة في حالة المدخلات مختلطة الألوان). يتيح ذلك للمستخدمين الاحتفاظ بمحافظ تحتوي فقط على UTXO بلون معين وإرسالها تمامًا مثل عملات بيتكوين العادية، مع التراجع عبر سلسلة الكتل لتحديد لون أي UTXO يتلقونه.
• العملات الفوقية (Metacoins) - الفكرة وراء العملة الفوقية هي أن يكون هناك بروتوكول يعيش فوق بيتكوين، باستخدام معاملات بيتكوين لتخزين معاملات العملة الفوقية ولكن مع وجود دالة انتقال حالة مختلفة، APPLY'. نظرًا لأن بروتوكول العملة الفوقية لا يمكنه منع ظهور معاملات العملة الفوقية غير الصالحة في سلسلة كتل بيتكوين، تتم إضافة قاعدة مفادها أنه إذا أرجعت APPLY'(S,TX) خطأ، فإن البروتوكول يعود افتراضيًا إلى APPLY'(S,TX) = S. يوفر هذا آلية سهلة لإنشاء بروتوكول عملة مشفرة عشوائي، ومن المحتمل أن يحتوي على ميزات متقدمة لا يمكن تنفيذها داخل بيتكوين نفسه، ولكن بتكلفة تطوير منخفضة جدًا نظرًا لأن تعقيدات التعدين والشبكات يتم التعامل معها بالفعل بواسطة بروتوكول بيتكوين. تم استخدام العملات الفوقية لتنفيذ بعض فئات العقود المالية، وتسجيل الأسماء، والتبادل اللامركزي.

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

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

البرمجة النصية

حتى بدون أي امتدادات، فإن بروتوكول بيتكوين يسهل في الواقع إصدارًا ضعيفًا من مفهوم "العقود الذكية". يمكن أن تكون UTXO في بيتكوين مملوكة ليس فقط لمفتاح عام، ولكن أيضًا لبرنامج نصي أكثر تعقيدًا يتم التعبير عنه بلغة برمجة بسيطة تعتمد على المكدس (stack-based). في هذا النموذج، يجب أن توفر المعاملة التي تنفق UTXO هذا بيانات تلبي البرنامج النصي. في الواقع، حتى آلية ملكية المفتاح العام الأساسية يتم تنفيذها عبر برنامج نصي: يأخذ البرنامج النصي توقيع منحنى إهليلجي كمدخل، ويتحقق منه مقابل المعاملة والعنوان الذي يمتلك UTXO، ويرجع 1 إذا كان التحقق ناجحًا و 0 بخلاف ذلك. توجد برامج نصية أخرى أكثر تعقيدًا لحالات استخدام إضافية مختلفة. على سبيل المثال، يمكن للمرء إنشاء برنامج نصي يتطلب توقيعات من اثنين من أصل ثلاثة مفاتيح خاصة معينة للتحقق ("متعدد التوقيعات")، وهو إعداد مفيد لحسابات الشركات، وحسابات التوفير الآمنة، وبعض حالات الضمان التجاري. يمكن أيضًا استخدام البرامج النصية لدفع مكافآت لحلول المشكلات الحسابية، ويمكن للمرء حتى إنشاء برنامج نصي يقول شيئًا مثل "إن UTXO الخاص ببيتكوين هذا ملكك إذا تمكنت من تقديم إثبات SPV بأنك أرسلت معاملة Dogecoin بهذه الفئة إلي"، مما يسمح بشكل أساسي بتبادل العملات المشفرة اللامركزي عبر السلاسل.

ومع ذلك، فإن لغة البرمجة النصية كما هي مطبقة في بيتكوين لها العديد من القيود المهمة:

• الافتقار إلى اكتمال تورينج (Turing-completeness) - أي أنه على الرغم من وجود مجموعة فرعية كبيرة من العمليات الحسابية التي تدعمها لغة البرمجة النصية لبيتكوين، إلا أنها لا تدعم كل شيء تقريبًا. الفئة الرئيسية المفقودة هي الحلقات (loops). يتم ذلك لتجنب الحلقات اللانهائية أثناء التحقق من المعاملة؛ من الناحية النظرية، إنها عقبة يمكن التغلب عليها لمبرمجي البرامج النصية، حيث يمكن محاكاة أي حلقة ببساطة عن طريق تكرار الكود الأساسي عدة مرات باستخدام عبارة if، ولكنها تؤدي إلى برامج نصية غير فعالة للغاية من حيث المساحة. على سبيل المثال، من المحتمل أن يتطلب تنفيذ خوارزمية توقيع منحنى إهليلجي بديلة 256 جولة ضرب متكررة يتم تضمينها جميعًا بشكل فردي في الكود.
• العمى عن القيمة (Value-blindness) - لا توجد طريقة لبرنامج UTXO النصي لتوفير تحكم دقيق في المبلغ الذي يمكن سحبه. على سبيل المثال، إحدى حالات الاستخدام القوية لعقد أوراكل ستكون عقد تحوط، حيث يضع A و B ما قيمته $1000 من BTC وبعد 30 يومًا يرسل البرنامج النصي ما قيمته $1000 من BTC إلى A والباقي إلى B. سيتطلب هذا أوراكل لتحديد قيمة 1 BTC بالدولار الأمريكي، ولكن حتى مع ذلك فهو تحسن هائل من حيث الثقة ومتطلبات البنية التحتية مقارنة بالحلول المركزية بالكامل المتاحة الآن. ومع ذلك، نظرًا لأن UTXO هي إما كل شيء أو لا شيء، فإن الطريقة الوحيدة لتحقيق ذلك هي من خلال حيلة غير فعالة للغاية تتمثل في وجود العديد من UTXO بفئات مختلفة (على سبيل المثال، UTXO واحد بقيمة 2^k لكل k حتى 30) وجعل أوراكل يختار أي UTXO يرسله إلى A وأيها إلى B.
• الافتقار إلى الحالة - يمكن إما إنفاق UTXO أو عدم إنفاقه؛ لا توجد فرصة للعقود أو البرامج النصية متعددة المراحل التي تحتفظ بأي حالة داخلية أخرى تتجاوز ذلك. هذا يجعل من الصعب إنشاء عقود خيارات متعددة المراحل، أو عروض تبادل لامركزية، أو بروتوكولات التزام تشفيري من مرحلتين (ضرورية للمكافآت الحسابية الآمنة). وهذا يعني أيضًا أنه لا يمكن استخدام UTXO إلا لبناء عقود بسيطة لمرة واحدة وليس عقودًا "ذات حالة" أكثر تعقيدًا مثل المنظمات اللامركزية، ويجعل من الصعب تنفيذ البروتوكولات الفوقية. الحالة الثنائية جنبًا إلى جنب مع العمى عن القيمة تعني أيضًا أن تطبيقًا مهمًا آخر، وهو حدود السحب، مستحيل.
• العمى عن سلسلة الكتل (Blockchain-blindness) - إن UTXO عمياء عن بيانات سلسلة الكتل مثل الرقم الفريد (nonce)، والطابع الزمني، وتجزئة الكتلة السابقة. هذا يحد بشدة من التطبيقات في المقامرة، والعديد من الفئات الأخرى، من خلال حرمان لغة البرمجة النصية من مصدر قيم محتمل للعشوائية.

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

إيثيريوم

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

حسابات إيثيريوم

في إيثيريوم، تتكون الحالة من كائنات تسمى "حسابات"، حيث يمتلك كل حساب عنوانًا بحجم 20-byte وتكون انتقالات الحالة عبارة عن تحويلات مباشرة للقيمة والمعلومات بين الحسابات. يحتوي حساب إيثيريوم على أربعة حقول:

• الرقم الفريد (nonce)، وهو عداد يُستخدم للتأكد من إمكانية معالجة كل معاملة مرة واحدة فقط
• رصيد الإيثر الحالي للحساب
• رمز العقد الخاص بالحساب، إن وجد
• تخزين الحساب (فارغ افتراضيًا)

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

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

الرسائل والمعاملات

يُستخدم مصطلح "معاملة" في إيثيريوم للإشارة إلى حزمة البيانات الموقعة التي تخزن رسالة ليتم إرسالها من حساب مملوك خارجيًا. تحتوي المعاملات على:

• مستلم الرسالة
• توقيع يحدد هوية المرسل
• مقدار الإيثر المراد تحويله من المرسل إلى المستلم
• حقل بيانات اختياري
• قيمة STARTGAS، تمثل الحد الأقصى لعدد الخطوات الحسابية المسموح بتنفيذها في المعاملة
• قيمة GASPRICE، تمثل الرسوم التي يدفعها المرسل لكل خطوة حسابية

الحقول الثلاثة الأولى هي حقول قياسية متوقعة في أي عملة مشفرة. لا يحتوي حقل البيانات على وظيفة افتراضيًا، ولكن الجهاز الظاهري يحتوي على رمز تشغيل (opcode) يمكن للعقد من خلاله الوصول إلى البيانات؛ وكمثال على حالة الاستخدام، إذا كان العقد يعمل كخدمة تسجيل نطاق على السلسلة (onchain)، فقد يرغب في تفسير البيانات التي يتم تمريرها إليه على أنها تحتوي على "حقلين"، الحقل الأول هو النطاق المراد تسجيله والحقل الثاني هو عنوان IP المراد تسجيله فيه. سيقرأ العقد هذه القيم من بيانات الرسالة ويضعها بشكل مناسب في التخزين.

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

الرسائل

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

• مرسل الرسالة (ضمني)
• مستلم الرسالة
• مقدار الإيثر المراد تحويله مع الرسالة
• حقل بيانات اختياري
• قيمة STARTGAS

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

لاحظ أن سماحية الغاز المخصصة بواسطة معاملة أو عقد تنطبق على إجمالي الغاز المستهلك بواسطة تلك المعاملة وجميع عمليات التنفيذ الفرعية. على سبيل المثال، إذا أرسلت جهة فاعلة خارجية A معاملة إلى B مع 1000 gas، واستهلك B 600 gas قبل إرسال رسالة إلى C، واستهلك التنفيذ الداخلي لـ C 300 gas قبل العودة، فيمكن لـ B إنفاق 100 gas أخرى قبل نفاد الغاز.

دالة انتقال حالة إيثيريوم

يمكن تعريف دالة انتقال حالة إيثيريوم، APPLY(S,TX) -> S' على النحو التالي:

1. تحقق مما إذا كانت المعاملة جيدة التكوين (أي تحتوي على العدد الصحيح من القيم)، وأن التوقيع صالح، وأن الرقم الفريد يتطابق مع الرقم الفريد في حساب المرسل. إذا لم يكن كذلك، فقم بإرجاع خطأ.
2. احسب رسوم المعاملة كـ STARTGAS * GASPRICE، وحدد عنوان الإرسال من التوقيع. اطرح الرسوم من رصيد حساب المرسل وقم بزيادة الرقم الفريد للمرسل. إذا لم يكن هناك رصيد كافٍ للإنفاق، فقم بإرجاع خطأ.
3. قم بتهيئة GAS = STARTGAS، واخصم كمية معينة من الغاز لكل بايت لدفع ثمن البايتات في المعاملة.
4. قم بتحويل قيمة المعاملة من حساب المرسل إلى الحساب المستلم. إذا لم يكن الحساب المستلم موجودًا بعد، فقم بإنشائه. إذا كان الحساب المستلم عبارة عن عقد، فقم بتشغيل رمز العقد إما حتى الاكتمال أو حتى ينفد الغاز من التنفيذ.
5. إذا فشل تحويل القيمة لأن المرسل لم يكن لديه أموال كافية، أو نفد الغاز من تنفيذ التعليمات البرمجية، فتراجع عن جميع تغييرات الحالة باستثناء دفع الرسوم، وأضف الرسوم إلى حساب المُعَدِّن.
6. بخلاف ذلك، قم برد الرسوم لجميع الغاز المتبقي إلى المرسل، وأرسل الرسوم المدفوعة للغاز المستهلك إلى المُعَدِّن.

على سبيل المثال، لنفترض أن رمز العقد هو:

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

لاحظ أنه في الواقع تتم كتابة رمز العقد برمز EVM منخفض المستوى؛ هذا المثال مكتوب بلغة Serpent، وهي إحدى لغاتنا عالية المستوى، من أجل الوضوح، ويمكن تجميعها إلى رمز EVM. لنفترض أن تخزين العقد يبدأ فارغًا، ويتم إرسال معاملة بقيمة 10 ether، و 2000 gas، وسعر غاز 0.001 ether، و 64 bytes من البيانات، حيث تمثل البايتات 0-31 الرقم 2 وتمثل البايتات 32-63 السلسلة CHARLIE^fn3. عملية دالة انتقال الحالة في هذه الحالة هي كما يلي:

1. تحقق من أن المعاملة صالحة وجيدة التكوين.
2. تحقق من أن مرسل المعاملة لديه على الأقل 2000 * 0.001 = 2 ether. إذا كان الأمر كذلك، فاطرح 2 ether من حساب المرسل.
3. قم بتهيئة الغاز = 2000؛ بافتراض أن طول المعاملة هو 170 bytes ورسوم البايت هي 5، اطرح 850 بحيث يتبقى 1150 gas.
4. اطرح 10 ether إضافية من حساب المرسل، وأضفها إلى حساب العقد.
5. قم بتشغيل الرمز. في هذه الحالة، هذا بسيط: يتحقق مما إذا كان تخزين العقد عند المؤشر 2 مستخدمًا، ويلاحظ أنه ليس كذلك، لذلك يقوم بتعيين التخزين عند المؤشر 2 إلى القيمة CHARLIE. لنفترض أن هذا يستغرق 187 gas، وبالتالي فإن كمية الغاز المتبقية هي 1150 - 187 = 963
6. أضف 963 * 0.001 = 0.963 ether مرة أخرى إلى حساب المرسل، وأرجع الحالة الناتجة.

إذا لم يكن هناك عقد في الطرف المتلقي للمعاملة، فإن إجمالي رسوم المعاملة سيكون ببساطة مساويًا لـ GASPRICE المقدم مضروبًا في طول المعاملة بالبايت، وستكون البيانات المرسلة مع المعاملة غير ذات صلة.

لاحظ أن الرسائل تعمل بشكل مكافئ للمعاملات من حيث التراجع: إذا نفد الغاز من تنفيذ رسالة، فإن تنفيذ تلك الرسالة، وجميع عمليات التنفيذ الأخرى التي تم تشغيلها بواسطة هذا التنفيذ، تتراجع، ولكن لا تحتاج عمليات التنفيذ الأصلية إلى التراجع. هذا يعني أنه من "الآمن" لعقد أن يستدعي عقدًا آخر، كما لو أن A يستدعي B بـ G من الغاز، فإن تنفيذ A مضمون أن يخسر على الأكثر G من الغاز. أخيرًا، لاحظ أن هناك رمز تشغيل، CREATE، يقوم بإنشاء عقد؛ آليات تنفيذه مشابهة بشكل عام لـ CALL، باستثناء أن مخرجات التنفيذ تحدد رمز العقد المنشأ حديثًا.

تنفيذ التعليمات البرمجية

تتم كتابة التعليمات البرمجية في عقود إيثيريوم بلغة رمز البايت (bytecode) منخفضة المستوى تعتمد على المكدس (stack)، ويشار إليها باسم "رمز آلة إيثيريوم الافتراضية" أو "رمز EVM". يتكون الرمز من سلسلة من البايتات، حيث يمثل كل بايت عملية. بشكل عام، تنفيذ التعليمات البرمجية عبارة عن حلقة لا نهائية تتكون من تنفيذ العملية بشكل متكرر عند عداد البرنامج الحالي (والذي يبدأ من الصفر) ثم زيادة عداد البرنامج بمقدار واحد، حتى يتم الوصول إلى نهاية الرمز أو يتم اكتشاف خطأ أو تعليمة STOP أو RETURN. تتمتع العمليات بإمكانية الوصول إلى ثلاثة أنواع من المساحات لتخزين البيانات فيها:

• المكدس (stack)، وهو حاوية من نوع "ما يدخل أخيرًا يخرج أولاً" (LIFO) يمكن دفع القيم إليها وسحبها منها
• الذاكرة، وهي مصفوفة بايتات قابلة للتوسيع بشكل لا نهائي
• التخزين طويل الأجل للعقد، وهو مخزن مفتاح/قيمة. على عكس المكدس والذاكرة، اللذين يتم إعادة تعيينهما بعد انتهاء الحساب، يستمر التخزين على المدى الطويل.

يمكن للرمز أيضًا الوصول إلى القيمة والمرسل وبيانات الرسالة الواردة، بالإضافة إلى بيانات رأس الكتلة، ويمكن للرمز أيضًا إرجاع مصفوفة بايتات من البيانات كمخرجات.

نموذج التنفيذ الرسمي لرمز EVM بسيط بشكل مدهش. أثناء تشغيل آلة إيثيريوم الافتراضية، يمكن تعريف حالتها الحسابية الكاملة بواسطة المجموعة (tuple) (block_state, transaction, message, code, memory, stack, pc, gas)، حيث block_state هي الحالة العالمية التي تحتوي على جميع الحسابات وتتضمن الأرصدة والتخزين. في بداية كل جولة من التنفيذ، يتم العثور على التعليمة الحالية عن طريق أخذ البايت pc من code (أو 0 إذا كان pc >= len(code))، ولكل تعليمة تعريفها الخاص من حيث كيفية تأثيرها على المجموعة. على سبيل المثال، يقوم ADD بسحب عنصرين من المكدس ودفع مجموعهما، ويقلل gas بمقدار 1 ويزيد pc بمقدار 1، ويقوم SSTORE بسحب العنصرين العلويين من المكدس وإدراج العنصر الثاني في تخزين العقد عند المؤشر المحدد بواسطة العنصر الأول. على الرغم من وجود العديد من الطرق لتحسين تنفيذ آلة إيثيريوم الافتراضية عبر التجميع في الوقت المناسب (JIT)، يمكن إجراء تنفيذ أساسي لإيثيريوم في بضع مئات من أسطر التعليمات البرمجية.

سلسلة الكتل والتعدين

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

1. تحقق مما إذا كانت الكتلة السابقة المشار إليها موجودة وصالحة.
2. تحقق من أن الطابع الزمني للكتلة أكبر من الطابع الزمني للكتلة السابقة المشار إليها وأقل من 15 دقيقة في المستقبل
3. تحقق من أن رقم الكتلة، والصعوبة، وجذر المعاملة، وجذر العم (uncle root)، وحد الغاز (مفاهيم مختلفة منخفضة المستوى خاصة بإيثيريوم) صالحة.
4. تحقق من أن إثبات العمل (PoW) على الكتلة صالح.
5. لتكن S[0] هي الحالة في نهاية الكتلة السابقة.
6. لتكن TX هي قائمة معاملات الكتلة، مع n من المعاملات. لجميع i في 0...n-1، قم بتعيين S[i+1] = APPLY(S[i],TX[i]). إذا أرجعت أي تطبيقات خطأ، أو إذا تجاوز إجمالي الغاز المستهلك في الكتلة حتى هذه النقطة GASLIMIT، فقم بإرجاع خطأ.
7. لتكن S_FINAL هي S[n]، ولكن مع إضافة مكافأة الكتلة المدفوعة إلى المُعَدِّن.
8. تحقق مما إذا كان جذر شجرة ميركل للحالة S_FINAL يساوي جذر الحالة النهائي المقدم في رأس الكتلة. إذا كان كذلك، فإن الكتلة صالحة؛ وإلا فهي غير صالحة.

قد يبدو النهج غير فعال للغاية للوهلة الأولى، لأنه يحتاج إلى تخزين الحالة بأكملها مع كل كتلة، ولكن في الواقع يجب أن تكون الكفاءة قابلة للمقارنة بكفاءة بيتكوين. السبب هو أن الحالة يتم تخزينها في بنية الشجرة، وبعد كل كتلة لا يلزم تغيير سوى جزء صغير من الشجرة. وبالتالي، بشكل عام، بين كتلتين متجاورتين، يجب أن تكون الغالبية العظمى من الشجرة هي نفسها، وبالتالي يمكن تخزين البيانات مرة واحدة والإشارة إليها مرتين باستخدام المؤشرات (أي تجزئات الأشجار الفرعية). يتم استخدام نوع خاص من الأشجار يُعرف باسم "شجرة باتريشيا" (Patricia tree) لإنجاز ذلك، بما في ذلك تعديل على مفهوم شجرة ميركل يسمح بإدراج العقد وحذفها، وليس فقط تغييرها، بكفاءة. بالإضافة إلى ذلك، نظرًا لأن جميع معلومات الحالة هي جزء من الكتلة الأخيرة، فلا داعي لتخزين سجل سلسلة الكتل بالكامل - وهي استراتيجية، إذا أمكن تطبيقها على بيتكوين، يمكن حسابها لتوفير وفورات في المساحة بمقدار 5-20x.

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

التطبيقات

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

أنظمة الرموز المميزة

تمتلك أنظمة الرموز المميزة على سلسلة الكتل العديد من التطبيقات التي تتراوح من العملات الفرعية التي تمثل أصولًا مثل الدولار الأمريكي (USD) أو الذهب إلى أسهم الشركات، والرموز المميزة الفردية التي تمثل الملكية الذكية، والقسائم الآمنة غير القابلة للتزوير، وحتى أنظمة الرموز المميزة التي لا ترتبط بأي قيمة تقليدية على الإطلاق، وتُستخدم كأنظمة نقاط للتحفيز. من السهل بشكل مدهش تنفيذ أنظمة الرموز المميزة في إيثيريوم. النقطة الأساسية التي يجب فهمها هي أن كل ما تمثله العملة، أو نظام الرموز المميزة، في الأساس، هو قاعدة بيانات بعملية واحدة: طرح X من الوحدات من A وإعطاء X من الوحدات إلى B، بشرط أن (1) كان لدى A على الأقل X من الوحدات قبل المعاملة و(2) تمت الموافقة على المعاملة من قبل A. كل ما يتطلبه الأمر لتنفيذ نظام رموز مميزة هو تنفيذ هذا المنطق في عقد.

يبدو الرمز الأساسي لتنفيذ نظام رموز مميزة في Serpent كما يلي:

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

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

المشتقات المالية والعملات ذات القيمة المستقرة

المشتقات المالية هي التطبيق الأكثر شيوعًا لـ "عقد ذكي"، وواحدة من أبسط التطبيقات التي يمكن تنفيذها في التعليمات البرمجية. التحدي الرئيسي في تنفيذ العقود المالية هو أن غالبيتها تتطلب الرجوع إلى مؤشر أسعار خارجي؛ على سبيل المثال، من التطبيقات المرغوبة للغاية عقد ذكي يتحوط ضد تقلبات الإيثر (أو عملة مشفرة أخرى) فيما يتعلق بالدولار الأمريكي، ولكن القيام بذلك يتطلب أن يعرف العقد ما هي قيمة ETH/USD. أبسط طريقة للقيام بذلك هي من خلال عقد "تغذية بيانات" يحتفظ به طرف معين (مثل NASDAQ) مصمم بحيث يكون لدى هذا الطرف القدرة على تحديث العقد حسب الحاجة، وتوفير واجهة تسمح للعقود الأخرى بإرسال رسالة إلى ذلك العقد والحصول على استجابة توفر السعر.

بالنظر إلى هذا المكون الحاسم، سيبدو عقد التحوط كما يلي:

1. انتظر حتى يقوم الطرف A بإدخال 1000 إيثر.
2. انتظر حتى يقوم الطرف B بإدخال 1000 إيثر.
3. سجل قيمة الدولار الأمريكي لـ 1000 إيثر، المحسوبة عن طريق الاستعلام من عقد تغذية البيانات، في التخزين، ولنقل أن هذا هو $x.
4. بعد 30 يومًا، اسمح لـ A أو B بـ "إعادة تنشيط" العقد من أجل إرسال ما قيمته $x من الإيثر (المحسوب عن طريق الاستعلام من عقد تغذية البيانات مرة أخرى للحصول على السعر الجديد) إلى A والباقي إلى B.

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

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

أنظمة الهوية والسمعة

حاولت أقدم عملة مشفرة بديلة على الإطلاق، Namecoin (opens in a new tab)، استخدام سلسلة كتل شبيهة بـ بيتكوين لتوفير نظام تسجيل أسماء، حيث يمكن للمستخدمين تسجيل أسمائهم في قاعدة بيانات عامة إلى جانب بيانات أخرى. حالة الاستخدام الرئيسية المذكورة هي لنظام DNS (opens in a new tab)، لربط أسماء النطاقات مثل "bitcoin.org" (أو، في حالة Namecoin، "bitcoin.bit") بعنوان IP. تشمل حالات الاستخدام الأخرى مصادقة البريد الإلكتروني وأنظمة سمعة أكثر تقدمًا. إليك العقد الأساسي لتوفير نظام تسجيل أسماء شبيه بـ Namecoin على إيثيريوم:

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

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

تخزين الملفات اللامركزي

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

سيكون الجزء الأساسي الداعم لمثل هذا الجهاز هو ما أطلقنا عليه "عقد Dropbox اللامركزي". يعمل هذا العقد على النحو التالي. أولاً، يقوم المرء بتقسيم البيانات المطلوبة إلى كتل، وتشفير كل كتلة من أجل الخصوصية، وبناء شجرة ميركل منها. ثم يقوم المرء بإبرام عقد بقاعدة تنص على أنه، كل N من الكتل، سيختار العقد مؤشرًا عشوائيًا في شجرة ميركل (باستخدام تجزئة الكتلة السابقة، والتي يمكن الوصول إليها من رمز العقد، كمصدر للعشوائية)، وإعطاء X إيثر لأول كيان يقدم معاملة مع إثبات ملكية يشبه التحقق المبسط من الدفع للكتلة في ذلك المؤشر المعين في الشجرة. عندما يريد المستخدم إعادة تنزيل ملفه، يمكنه استخدام بروتوكول قناة المدفوعات الصغيرة (على سبيل المثال، دفع 1 سابو لكل 32 كيلوبايت) لاستعادة الملف؛ النهج الأكثر كفاءة من حيث الرسوم هو ألا يقوم الدافع بنشر المعاملة حتى النهاية، وبدلاً من ذلك يستبدل المعاملة بأخرى أكثر ربحية قليلاً بنفس الرقم الفريد بعد كل 32 كيلوبايت.

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

المنظمات المستقلة اللامركزية

المفهوم العام لـ "المنظمة المستقلة اللامركزية" هو كيان افتراضي لديه مجموعة معينة من الأعضاء أو المساهمين الذين، ربما بأغلبية 67%، لديهم الحق في إنفاق أموال الكيان وتعديل رمزه. سيقرر الأعضاء بشكل جماعي كيفية تخصيص المنظمة لأموالها. يمكن أن تتراوح طرق تخصيص أموال المنظمة المستقلة اللامركزية (DAO) من المكافآت والرواتب إلى آليات أكثر غرابة مثل عملة داخلية لمكافأة العمل. هذا يكرر بشكل أساسي المظاهر القانونية لشركة تقليدية أو مؤسسة غير ربحية ولكن باستخدام تقنية سلسلة الكتل المشفرة فقط للتنفيذ. حتى الآن، كان الكثير من الحديث حول المنظمات المستقلة اللامركزية (DAOs) يدور حول النموذج "الرأسمالي" لـ "شركة مستقلة لامركزية" (DAC) مع مساهمين يتلقون أرباحًا وأسهم قابلة للتداول؛ البديل، الذي ربما يوصف بأنه "مجتمع مستقل لامركزي"، سيجعل جميع الأعضاء يتمتعون بحصة متساوية في صنع القرار ويتطلب موافقة 67% من الأعضاء الحاليين لإضافة أو إزالة عضو. سيتعين بعد ذلك تنفيذ شرط أن يكون لشخص واحد عضوية واحدة فقط بشكل جماعي من قبل المجموعة.

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

• [0,i,K,V] لتسجيل مقترح بمؤشر i لتغيير العنوان في مؤشر التخزين K إلى القيمة V
• [1,i] لتسجيل صوت لصالح المقترح i
• [2,i] لجعل المقترح i نهائيًا إذا تم الإدلاء بعدد كافٍ من الأصوات

سيحتوي العقد بعد ذلك على بنود لكل من هذه. سيحتفظ بسجل لجميع تغييرات التخزين المفتوحة، إلى جانب قائمة بمن صوتوا لها. سيكون لديه أيضًا قائمة بجميع الأعضاء. عندما يحصل أي تغيير في التخزين على تصويت ثلثي الأعضاء لصالحه، يمكن لمعاملة نهائية تنفيذ التغيير. سيحتوي الهيكل الأكثر تعقيدًا أيضًا على قدرة تصويت مدمجة لميزات مثل إرسال معاملة، وإضافة أعضاء وإزالة أعضاء، وقد يوفر حتى تفويض التصويت بأسلوب الديمقراطية السائلة (opens in a new tab) (أي يمكن لأي شخص تعيين شخص ما للتصويت نيابة عنه، والتعيين متعدٍ، فإذا قام A بتعيين B وقام B بتعيين C، فإن C يحدد صوت A). سيسمح هذا التصميم للمنظمة المستقلة اللامركزية بالنمو بشكل عضوي كمجتمع لامركزي، مما يسمح للأشخاص في النهاية بتفويض مهمة تصفية من هو عضو إلى متخصصين، على الرغم من أنه على عكس "النظام الحالي"، يمكن للمتخصصين الظهور والاختفاء بسهولة بمرور الوقت مع تغيير أفراد المجتمع لولاءاتهم.

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

تطبيقات إضافية

1. محافظ المدخرات. لنفترض أن أليس تريد الحفاظ على أموالها آمنة، لكنها قلقة من أن تفقد مفتاحها الخاص أو أن يقوم شخص ما باختراقه. تضع الإيثر في عقد مع بوب، وهو بنك، على النحو التالي:

• يمكن لأليس وحدها سحب حد أقصى يبلغ 1% من الأموال يوميًا.
• يمكن لبوب وحده سحب حد أقصى يبلغ 1% من الأموال يوميًا، ولكن لدى أليس القدرة على إجراء معاملة بمفتاحها لإيقاف هذه القدرة.
• يمكن لأليس وبوب معًا سحب أي مبلغ.

عادةً، 1% يوميًا يكفي لأليس، وإذا أرادت أليس سحب المزيد، فيمكنها الاتصال بـ بوب للحصول على المساعدة. إذا تم اختراق مفتاح أليس، فإنها تسرع إلى بوب لنقل الأموال إلى عقد جديد. إذا فقدت مفتاحها، فسيقوم بوب بإخراج الأموال في النهاية. إذا تبين أن بوب خبيث، فيمكنها إيقاف قدرته على السحب.

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

3. تغذية بيانات لامركزية. بالنسبة للعقود المالية مقابل الفروقات، قد يكون من الممكن بالفعل جعل تغذية البيانات لامركزية عبر بروتوكول يسمى "SchellingCoin (opens in a new tab)". يعمل SchellingCoin بشكل أساسي على النحو التالي: تضع N من الأطراف جميعها في النظام قيمة معطى معين (مثل سعر ETH/USD)، ويتم فرز القيم، ويحصل كل شخص بين الشريحة المئوية 25 و 75 على رمز مميز واحد كمكافأة. لدى الجميع الحافز لتقديم الإجابة التي سيقدمها أي شخص آخر، والقيمة الوحيدة التي يمكن لعدد كبير من اللاعبين الاتفاق عليها بشكل واقعي هي الافتراضي الواضح: الحقيقة. يؤدي هذا إلى إنشاء بروتوكول لامركزي يمكنه نظريًا توفير أي عدد من القيم، بما في ذلك سعر ETH/USD، أو درجة الحرارة في برلين أو حتى نتيجة عملية حسابية صعبة معينة.

4. حساب ضمان ذكي متعدد التوقيعات. يسمح بيتكوين بعقود معاملات متعددة التوقيعات حيث، على سبيل المثال، يمكن لثلاثة من أصل خمسة مفاتيح معينة إنفاق الأموال. يسمح إيثيريوم بمزيد من الدقة؛ على سبيل المثال، يمكن لأربعة من أصل خمسة إنفاق كل شيء، ويمكن لثلاثة من أصل خمسة إنفاق ما يصل إلى 10% يوميًا، ويمكن لاثنين من أصل خمسة إنفاق ما يصل إلى 0.5% يوميًا. بالإضافة إلى ذلك، فإن التوقيع المتعدد (multisig) في إيثيريوم غير متزامن - يمكن لطرفين تسجيل توقيعاتهما على سلسلة الكتل في أوقات مختلفة وسيقوم التوقيع الأخير بإرسال المعاملة تلقائيًا.

5. الحوسبة السحابية. يمكن أيضًا استخدام تقنية EVM لإنشاء بيئة حوسبة يمكن التحقق منها، مما يسمح للمستخدمين بمطالبة الآخرين بإجراء عمليات حسابية ثم طلب إثباتات اختياريًا على أن العمليات الحسابية في نقاط تفتيش معينة تم اختيارها عشوائيًا قد تمت بشكل صحيح. يسمح هذا بإنشاء سوق حوسبة سحابية حيث يمكن لأي مستخدم المشاركة باستخدام جهاز الكمبيوتر المكتبي أو المحمول أو الخادم المتخصص الخاص به، ويمكن استخدام الفحص العشوائي مع ودائع الأمان لضمان أن النظام جدير بالثقة (أي لا يمكن للعقد الغش بشكل مربح). على الرغم من أن مثل هذا النظام قد لا يكون مناسبًا لجميع المهام؛ فإن المهام التي تتطلب مستوى عاليًا من الاتصال بين العمليات، على سبيل المثال، لا يمكن القيام بها بسهولة على سحابة كبيرة من العقد. ومع ذلك، فإن المهام الأخرى أسهل بكثير في الموازاة؛ يمكن بسهولة تنفيذ مشاريع مثل SETI@home و folding@home والخوارزميات الجينية فوق مثل هذه المنصة.

6. المقامرة من نظير إلى نظير. يمكن تنفيذ أي عدد من بروتوكولات المقامرة من نظير إلى نظير، مثل Cyberdice (opens in a new tab) لفرانك ستاجانو وريتشارد كلايتون، على سلسلة كتل إيثيريوم. أبسط بروتوكول مقامرة هو في الواقع ببساطة عقد مقابل الفروقات على تجزئة الكتلة التالية، ويمكن بناء بروتوكولات أكثر تقدمًا من هناك، مما يؤدي إلى إنشاء خدمات مقامرة برسوم تقترب من الصفر وليس لديها القدرة على الغش.

7. أسواق التنبؤ. شريطة وجود أوراكل أو SchellingCoin، من السهل أيضًا تنفيذ أسواق التنبؤ، وقد تثبت أسواق التنبؤ جنبًا إلى جنب مع SchellingCoin أنها أول تطبيق سائد لـ futarchy (opens in a new tab) كبروتوكول حوكمة للمنظمات اللامركزية.

8. أسواق لامركزية على السلسلة، باستخدام نظام الهوية والسمعة كأساس.

متفرقات ومخاوف

تنفيذ GHOST المُعدل

بروتوكول "Greedy Heaviest Observed Subtree" (GHOST) هو ابتكار قدمه لأول مرة يوناتان سومبولينسكي وأفيف زوهار في ديسمبر 2013 (opens in a new tab). الدافع وراء GHOST هو أن سلاسل الكتل (blockchains) ذات أوقات التأكيد السريعة تعاني حاليًا من انخفاض الأمان بسبب ارتفاع معدل الكتل القديمة (stale rate) - نظرًا لأن الكتل تستغرق وقتًا معينًا للانتشار عبر الشبكة، فإذا قام المُعَدِّن (أ) بتعدين كتلة ثم تصادف أن قام المُعَدِّن (ب) بتعدين كتلة أخرى قبل أن تنتشر كتلة المُعَدِّن (أ) إلى (ب)، فإن كتلة المُعَدِّن (ب) ستضيع هباءً ولن تساهم في أمان الشبكة. علاوة على ذلك، هناك مشكلة مركزية: إذا كان المُعَدِّن (أ) عبارة عن مجمع تعدين يمتلك 30% من قوة التجزئة وكان (ب) يمتلك 10% من قوة التجزئة، فسيكون لدى (أ) خطر إنتاج كتلة قديمة بنسبة 70% من الوقت (نظرًا لأن الـ 30% الأخرى من الوقت أنتج فيها (أ) الكتلة الأخيرة وبالتالي سيحصل على بيانات التعدين على الفور) بينما سيكون لدى (ب) خطر إنتاج كتلة قديمة بنسبة 90% من الوقت. وبالتالي، إذا كان الفاصل الزمني للكتلة قصيرًا بما يكفي ليكون معدل الكتل القديمة مرتفعًا، فسيكون (أ) أكثر كفاءة بشكل كبير ببساطة بحكم حجمه. مع الجمع بين هذين التأثيرين، من المرجح جدًا أن تؤدي سلاسل الكتل التي تنتج الكتل بسرعة إلى امتلاك مجمع تعدين واحد لنسبة كبيرة بما يكفي من قوة تجزئة الشبكة للسيطرة الفعلية على عملية التعدين.

كما وصف سومبولينسكي وزوهار، يحل GHOST المشكلة الأولى المتمثلة في فقدان أمان الشبكة من خلال تضمين الكتل القديمة في حساب أي سلسلة هي "الأطول"؛ بمعنى آخر، لا يتم فقط إضافة الأصل والأسلاف الأبعد للكتلة، بل يتم أيضًا إضافة الأحفاد القدامى لسلف الكتلة (في مصطلحات إيثيريوم، "الأعمام" (uncles)) إلى حساب أي كتلة لديها أكبر إجمالي إثبات العمل (PoW) يدعمها. لحل المشكلة الثانية المتمثلة في التحيز للمركزية، نتجاوز البروتوكول الذي وصفه سومبولينسكي وزوهار، ونقدم أيضًا مكافآت الكتلة للكتل القديمة: تتلقى الكتلة القديمة 87.5% من مكافأتها الأساسية، ويتلقى ابن الأخ (nephew) الذي يتضمن الكتلة القديمة الـ 12.5% المتبقية. ومع ذلك، لا تُمنح رسوم المعاملة للأعمام.

تنفذ إيثيريوم نسخة مبسطة من GHOST تنزل إلى سبعة مستويات فقط. على وجه التحديد، يتم تعريفها على النحو التالي:

• يجب أن تحدد الكتلة أصلًا (parent)، ويجب أن تحدد 0 أو أكثر من الأعمام (uncles)
• يجب أن يتمتع العم المُضمَّن في الكتلة (ب) بالخصائص التالية:
  • يجب أن يكون ابنًا مباشرًا لسلف الجيل k للكتلة (ب)، حيث 2 <= k <= 7.
  • لا يمكن أن يكون سلفًا للكتلة (ب)
  • يجب أن يكون العم رأس كتلة صالحًا، ولكن لا يلزم أن يكون كتلة تم التحقق منها مسبقًا أو حتى كتلة صالحة
  • يجب أن يكون العم مختلفًا عن جميع الأعمام المُضمَّنين في الكتل السابقة وجميع الأعمام الآخرين المُضمَّنين في نفس الكتلة (عدم التضمين المزدوج)
• لكل عم (U) في الكتلة (ب)، يحصل مُعَدِّن (ب) على 3.125% إضافية تُضاف إلى مكافأة كوين بيس (coinbase) الخاصة به ويحصل مُعَدِّن (U) على 93.75% من مكافأة كوين بيس القياسية.

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

الرسوم

نظرًا لأن كل معاملة تُنشر في سلسلة الكتل تفرض على الشبكة تكلفة الحاجة إلى تنزيلها والتحقق منها، فهناك حاجة إلى بعض الآليات التنظيمية، والتي تتضمن عادةً رسوم المعاملة، لمنع إساءة الاستخدام. النهج الافتراضي، المستخدم في بيتكوين، هو الحصول على رسوم طوعية بحتة، والاعتماد على المُعَدِّنين للعمل كحراس بوابة وتحديد حدود دنيا ديناميكية. حظي هذا النهج بقبول كبير جدًا في مجتمع بيتكوين خاصةً لأنه "قائم على السوق"، مما يسمح للعرض والطلب بين المُعَدِّنين ومرسلي المعاملات بتحديد السعر. ومع ذلك، تكمن المشكلة في هذا المنطق في أن معالجة المعاملات ليست سوقًا؛ على الرغم من أنه من الجذاب بديهيًا تفسير معالجة المعاملات كخدمة يقدمها المُعَدِّن للمرسل، إلا أنه في الواقع ستحتاج كل معاملة يدرجها المُعَدِّن إلى المعالجة بواسطة كل عقدة في الشبكة، وبالتالي فإن الغالبية العظمى من تكلفة معالجة المعاملات تتحملها أطراف ثالثة وليس المُعَدِّن الذي يتخذ قرار تضمينها من عدمه. ومن ثم، فمن المرجح جدًا حدوث مشاكل مأساة المشاع (tragedy-of-the-commons).

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

1. تؤدي المعاملة إلى عمليات k، وتقدم المكافأة kR لأي مُعَدِّن يدرجها حيث يتم تعيين R بواسطة المرسل وتكون k و R مرئية (تقريبًا) للمُعَدِّن مسبقًا.
2. تكلفة معالجة العملية هي C لأي عقدة (أي أن جميع العقد لها كفاءة متساوية)
3. هناك N عقد تعدين، لكل منها قوة معالجة متساوية تمامًا (أي 1/N من الإجمالي)
4. لا توجد عقد كاملة غير مُعَدِّنة.

سيكون المُعَدِّن على استعداد لمعالجة معاملة إذا كانت المكافأة المتوقعة أكبر من التكلفة. وبالتالي، فإن المكافأة المتوقعة هي kR/N نظرًا لأن المُعَدِّن لديه فرصة 1/N لمعالجة الكتلة التالية، وتكلفة المعالجة للمُعَدِّن هي ببساطة kC. ومن ثم، سيدرج المُعَدِّنون المعاملات حيث kR/N > kC، أو R > NC. لاحظ أن R هي الرسوم لكل عملية التي يقدمها المرسل، وبالتالي فهي حد أدنى للفائدة التي يستمدها المرسل من المعاملة، و NC هي التكلفة التي تتحملها الشبكة بأكملها معًا لمعالجة عملية ما. ومن ثم، فإن لدى المُعَدِّنين الحافز لتضمين فقط تلك المعاملات التي تتجاوز فيها الفائدة النفعية الإجمالية التكلفة.

ومع ذلك، هناك العديد من الانحرافات المهمة عن تلك الافتراضات في الواقع:

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

يوفر (1) ميلًا للمُعَدِّن لتضمين عدد أقل من المعاملات، ويزيد (2) من NC؛ ومن ثم، فإن هذين التأثيرين يلغيان بعضهما البعض جزئيًا على الأقل.^{كيف؟ (opens in a new tab)} (3) و (4) هما المشكلة الرئيسية؛ لحلهما، نقوم ببساطة بتأسيس سقف عائم: لا يمكن أن تحتوي أي كتلة على عمليات أكثر من BLK_LIMIT_FACTOR ضعف المتوسط المتحرك الأسي طويل الأجل. على وجه التحديد:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR و EMA_FACTOR هما ثوابت سيتم تعيينها على 65536 و 1.5 في الوقت الحالي، ولكن من المرجح أن يتم تغييرهما بعد مزيد من التحليل.

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

الحوسبة واكتمال تورينج (Turing-Completeness)

ملاحظة مهمة هي أن آلة إيثيريوم الافتراضية (EVM) مكتملة تورينج (Turing-complete)؛ وهذا يعني أن كود EVM يمكنه تشفير أي عملية حسابية يمكن تصور تنفيذها، بما في ذلك الحلقات اللانهائية. يسمح كود EVM بالتكرار بطريقتين. أولاً، هناك تعليمة JUMP تسمح للبرنامج بالقفز مرة أخرى إلى نقطة سابقة في الكود، وتعليمة JUMPI للقيام بالقفز الشرطي، مما يسمح بعبارات مثل while x < 27: x = x * 2. ثانيًا، يمكن للعقود استدعاء عقود أخرى، مما قد يسمح بالتكرار من خلال العودية (recursion). يؤدي هذا بطبيعة الحال إلى مشكلة: هل يمكن للمستخدمين الخبثاء إيقاف تشغيل المُعَدِّنين والعقد الكاملة بشكل أساسي عن طريق إجبارهم على الدخول في حلقة لانهائية؟ تنشأ المشكلة بسبب مشكلة في علوم الكمبيوتر تُعرف باسم مشكلة التوقف (halting problem): لا توجد طريقة لمعرفة، في الحالة العامة، ما إذا كان برنامج معين سيتوقف أم لا.

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

• يقوم المهاجم بإنشاء عقد يُشغِّل حلقة لانهائية، ثم يرسل معاملة تُنشِّط تلك الحلقة إلى المُعَدِّن. سيقوم المُعَدِّن بمعالجة المعاملة، وتشغيل الحلقة اللانهائية، والانتظار حتى ينفد الغاز. على الرغم من نفاد الغاز من التنفيذ وتوقفه في منتصف الطريق، إلا أن المعاملة تظل صالحة ولا يزال المُعَدِّن يطالب بالرسوم من المهاجم عن كل خطوة حسابية.
• يقوم المهاجم بإنشاء حلقة لانهائية طويلة جدًا بقصد إجبار المُعَدِّن على الاستمرار في الحوسبة لفترة طويلة بحيث بحلول الوقت الذي تنتهي فيه الحوسبة، ستكون قد ظهرت بضع كتل أخرى ولن يكون من الممكن للمُعَدِّن تضمين المعاملة للمطالبة بالرسوم. ومع ذلك، سيُطلب من المهاجم تقديم قيمة لـ STARTGAS تحد من عدد الخطوات الحسابية التي يمكن أن يستغرقها التنفيذ، لذلك سيعرف المُعَدِّن مسبقًا أن الحساب سيستغرق عددًا كبيرًا جدًا من الخطوات.
• يرى المهاجم عقدًا يحتوي على كود من شكل ما مثل send(A,contract.storage[A]); contract.storage[A] = 0، ويرسل معاملة تحتوي على غاز يكفي فقط لتشغيل الخطوة الأولى ولكن ليس الثانية (أي إجراء سحب ولكن عدم السماح للرصيد بالانخفاض). لا يحتاج مؤلف العقد إلى القلق بشأن الحماية من مثل هذه الهجمات، لأنه إذا توقف التنفيذ في منتصف الطريق، يتم التراجع عن التغييرات.
• يعمل العقد المالي عن طريق أخذ متوسط تسع تغذيات بيانات خاصة من أجل تقليل المخاطر. يستولي المهاجم على إحدى تغذيات البيانات، والتي تم تصميمها لتكون قابلة للتعديل عبر آلية استدعاء العنوان المتغير (variable-address-call) الموضحة في القسم الخاص بالمنظمات المستقلة اللامركزية (DAOs)، ويحولها لتشغيل حلقة لانهائية، وبالتالي محاولة إجبار أي محاولات للمطالبة بأموال من العقد المالي على نفاد الغاز. ومع ذلك، يمكن للعقد المالي تعيين حد الغاز على الرسالة لمنع هذه المشكلة.

البديل لاكتمال تورينج هو عدم اكتمال تورينج (Turing-incompleteness)، حيث لا توجد JUMP و JUMPI ويُسمح بوجود نسخة واحدة فقط من كل عقد في مكدس الاستدعاء (call stack) في أي وقت معين. مع هذا النظام، قد لا يكون نظام الرسوم الموصوف والشكوك حول فعالية حلنا ضروريًا، حيث ستكون تكلفة تنفيذ العقد مقيدة من الأعلى بحجمه. بالإضافة إلى ذلك، فإن عدم اكتمال تورينج ليس قيدًا كبيرًا إلى هذا الحد؛ من بين جميع أمثلة العقود التي تصورناها داخليًا، حتى الآن تطلب واحد فقط حلقة، وحتى تلك الحلقة يمكن إزالتها عن طريق إجراء 26 تكرارًا لقطعة كود من سطر واحد. بالنظر إلى الآثار الخطيرة لاكتمال تورينج، والفائدة المحدودة، لماذا لا يكون لدينا ببساطة لغة غير مكتملة تورينج؟ في الواقع، ومع ذلك، فإن عدم اكتمال تورينج بعيد كل البعد عن كونه حلاً أنيقًا للمشكلة. لمعرفة السبب، ضع في اعتبارك العقود التالية:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

الآن، أرسل معاملة إلى (A). وبالتالي، في 51 معاملة، لدينا عقد يستغرق 2⁵⁰ خطوة حسابية. يمكن للمُعَدِّنين محاولة اكتشاف مثل هذه القنابل المنطقية مسبقًا من خلال الاحتفاظ بقيمة بجانب كل عقد تحدد الحد الأقصى لعدد الخطوات الحسابية التي يمكن أن يستغرقها، وحساب ذلك للعقود التي تستدعي عقودًا أخرى بشكل متكرر، ولكن هذا سيتطلب من المُعَدِّنين حظر العقود التي تنشئ عقودًا أخرى (نظرًا لأن إنشاء وتنفيذ جميع العقود الـ 26 المذكورة أعلاه يمكن بسهولة دمجها في عقد واحد). نقطة أخرى إشكالية هي أن حقل العنوان للرسالة هو متغير، لذلك بشكل عام قد لا يكون من الممكن حتى معرفة العقود الأخرى التي سيستدعيها عقد معين مسبقًا. ومن ثم، في المجمل، لدينا استنتاج مفاجئ: من السهل بشكل مدهش إدارة اكتمال تورينج، ومن الصعب بشكل مدهش بنفس القدر إدارة الافتقار إلى اكتمال تورينج ما لم تكن نفس الضوابط الدقيقة موجودة - ولكن في هذه الحالة لماذا لا ندع البروتوكول يكون مكتمل تورينج؟

العملة والإصدار

تتضمن شبكة إيثيريوم عملتها المدمجة الخاصة، إيثر (ether)، والتي تخدم الغرض المزدوج المتمثل في توفير طبقة سيولة أساسية للسماح بالتبادل الفعال بين أنواع مختلفة من الأصول الرقمية، والأهم من ذلك، توفير آلية لدفع رسوم المعاملات. للراحة ولتجنب الجدل المستقبلي (انظر النقاش الحالي حول mBTC/uBTC/satoshi في بيتكوين)، سيتم تسمية الفئات مسبقًا:

• 1: Wei
• 10¹²: سابو
• 10¹⁵: فيني
• 10¹⁸: إيثر

يجب أن يؤخذ هذا كنسخة موسعة من مفهوم "الدولارات" و"السنتات" أو "BTC" و"ساتوشي". في المستقبل القريب، نتوقع أن يتم استخدام "إيثر" للمعاملات العادية، و"فيني" للمعاملات الصغيرة، و"سابو" و"Wei" للمناقشات الفنية حول الرسوم وتنفيذ البروتوكول؛ قد تصبح الفئات المتبقية مفيدة لاحقًا ولا ينبغي تضمينها في العملاء في هذه المرحلة.

سيكون نموذج الإصدار كما يلي:

• سيتم إصدار إيثر في عملية بيع عملة بسعر 1000-2000 إيثر لكل BTC، وهي آلية تهدف إلى تمويل منظمة إيثيريوم ودفع تكاليف التطوير التي تم استخدامها بنجاح من قبل منصات أخرى مثل Mastercoin و NXT. سيستفيد المشترون الأوائل من خصومات أكبر. سيتم استخدام BTC المستلمة من البيع بالكامل لدفع الرواتب والمكافآت للمطورين واستثمارها في مشاريع مختلفة هادفة للربح وغير هادفة للربح في نظام إيثيريوم والعملات المشفرة البيئي.
• سيتم تخصيص 0.099x من إجمالي المبلغ المباع (60102216 ETH) للمنظمة لتعويض المساهمين الأوائل ودفع النفقات المقومة بـ ETH قبل كتلة التكوين.
• سيتم الاحتفاظ بـ 0.099x من إجمالي المبلغ المباع كاحتياطي طويل الأجل.
• سيتم تخصيص 0.26x من إجمالي المبلغ المباع للمُعَدِّنين سنويًا إلى الأبد بعد تلك النقطة.

معدل نمو العرض طويل الأجل (بالنسبة المئوية)

على الرغم من الإصدار الخطي للعملة، تمامًا كما هو الحال مع بيتكوين بمرور الوقت، فإن معدل نمو العرض يميل مع ذلك إلى الصفر.

الخياران الرئيسيان في النموذج أعلاه هما (1) وجود وحجم مجمع الهبات (endowment pool)، و (2) وجود عرض خطي متزايد بشكل دائم، على عكس العرض المحدد بسقف كما في بيتكوين. مبرر مجمع الهبات هو كما يلي. إذا لم يكن مجمع الهبات موجودًا، وانخفض الإصدار الخطي إلى 0.217x لتوفير نفس معدل التضخم، فإن إجمالي كمية إيثر سيكون أقل بنسبة 16.5% وبالتالي ستكون كل وحدة أكثر قيمة بنسبة 19.8%. ومن ثم، في حالة التوازن، سيتم شراء إيثر أكثر بنسبة 19.8% في البيع، لذلك ستكون كل وحدة مرة أخرى بنفس القيمة تمامًا كما كانت من قبل. سيكون لدى المنظمة أيضًا 1.198x من BTC، والتي يمكن اعتبارها مقسمة إلى شريحتين: BTC الأصلية، والـ 0.198x الإضافية. ومن ثم، فإن هذا الوضع مكافئ تمامًا للهبة، ولكن مع اختلاف واحد مهم: تحتفظ المنظمة بـ BTC بحتة، وبالتالي لا يتم تحفيزها لدعم قيمة وحدة إيثر.

يقلل نموذج نمو العرض الخطي الدائم من خطر ما يراه البعض على أنه تركيز مفرط للثروة في بيتكوين، ويمنح الأفراد الذين يعيشون في العصور الحالية والمستقبلية فرصة عادلة للحصول على وحدات العملة، مع الاحتفاظ في نفس الوقت بحافز قوي للحصول على إيثر والاحتفاظ به لأن "معدل نمو العرض" كنسبة مئوية لا يزال يميل إلى الصفر بمرور الوقت. نفترض أيضًا أنه نظرًا لأن العملات المعدنية تُفقد دائمًا بمرور الوقت بسبب الإهمال والموت وما إلى ذلك، ويمكن نمذجة فقدان العملة كنسبة مئوية من إجمالي العرض سنويًا، فإن إجمالي المعروض من العملات المتداولة سيستقر في الواقع في النهاية عند قيمة تساوي الإصدار السنوي مقسومًا على معدل الخسارة (على سبيل المثال، بمعدل خسارة 1%، بمجرد أن يصل العرض إلى 26X، سيتم تعدين 0.26X وفقدان 0.26X كل عام، مما يخلق توازنًا).

لاحظ أنه في المستقبل، من المرجح أن تتحول إيثيريوم إلى نموذج إثبات الحصة (PoS) للأمان، مما يقلل من متطلبات الإصدار إلى ما بين الصفر و 0.05X سنويًا. في حالة فقدان منظمة إيثيريوم للتمويل أو اختفائها لأي سبب آخر، فإننا نترك "عقدًا اجتماعيًا" مفتوحًا: يحق لأي شخص إنشاء نسخة مرشحة مستقبلية من إيثيريوم، والشرط الوحيد هو أن كمية إيثر يجب أن تكون على الأكثر مساوية لـ 60102216 * (1.198 + 0.26 * n) حيث n هو عدد السنوات بعد كتلة التكوين. للمبدعين الحرية في البيع الجماعي أو تخصيص بعض أو كل الفرق بين توسع العرض المدفوع بـ PoS والحد الأقصى المسموح به لتوسع العرض لدفع تكاليف التطوير. الترقيات المرشحة التي لا تمتثل للعقد الاجتماعي يمكن تفرعها بشكل مبرر إلى إصدارات ممتثلة.

مركزية التعدين

تعمل خوارزمية تعدين بيتكوين من خلال جعل المُعَدِّنين يحسبون SHA-256 على إصدارات معدلة قليلاً من رأس الكتلة ملايين المرات مرارًا وتكرارًا، حتى تتوصل عقدة واحدة في النهاية إلى إصدار تكون تجزئته أقل من الهدف (حاليًا حوالي 2¹⁹²). ومع ذلك، فإن خوارزمية التعدين هذه عرضة لشكلين من أشكال المركزية. أولاً، أصبح نظام التعدين البيئي يهيمن عليه ASIC (الدوائر المتكاملة الخاصة بالتطبيقات)، وهي رقائق كمبيوتر مصممة من أجل، وبالتالي فهي أكثر كفاءة بآلاف المرات في، المهمة المحددة لتعدين بيتكوين. هذا يعني أن تعدين بيتكوين لم يعد مسعى لامركزيًا ومتكافئًا للغاية، حيث يتطلب ملايين الدولارات من رأس المال للمشاركة فيه بفعالية. ثانيًا، لا يقوم معظم مُعَدِّني بيتكوين في الواقع بإجراء تدقيق الكتلة محليًا؛ بدلاً من ذلك، يعتمدون على مجمع تعدين مركزي لتوفير رؤوس الكتل. يمكن القول إن هذه المشكلة أسوأ: اعتبارًا من وقت كتابة هذا التقرير، تتحكم أكبر ثلاثة مجمعات تعدين بشكل غير مباشر في حوالي 50% من قوة المعالجة في شبكة بيتكوين، على الرغم من أن هذا يتم التخفيف منه من خلال حقيقة أنه يمكن للمُعَدِّنين التبديل إلى مجمعات تعدين أخرى إذا حاول مجمع أو تحالف شن هجوم 51%.

النية الحالية في إيثيريوم هي استخدام خوارزمية تعدين يُطلب فيها من المُعَدِّنين جلب بيانات عشوائية من الحالة، وحساب بعض المعاملات المختارة عشوائيًا من آخر N من الكتل في سلسلة الكتل، وإرجاع تجزئة النتيجة. هذا له فائدتان مهمتان. أولاً، يمكن أن تتضمن عقود إيثيريوم أي نوع من الحوسبة، لذلك سيكون ASIC الخاص بإيثيريوم في الأساس ASIC للحوسبة العامة - أي وحدة معالجة مركزية (CPU) أفضل. ثانيًا، يتطلب التعدين الوصول إلى سلسلة الكتل بأكملها، مما يجبر المُعَدِّنين على تخزين سلسلة الكتل بأكملها وأن يكونوا على الأقل قادرين على التحقق من كل معاملة. هذا يزيل الحاجة إلى مجمعات التعدين المركزية؛ على الرغم من أن مجمعات التعدين لا يزال بإمكانها أن تخدم الدور المشروع المتمثل في تسوية عشوائية توزيع المكافآت، إلا أنه يمكن خدمة هذه الوظيفة بشكل جيد على حد سواء من خلال مجمعات نظير إلى نظير (peer-to-peer) دون سيطرة مركزية.

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

قابلية التوسع

أحد المخاوف الشائعة حول إيثيريوم هو مسألة قابلية التوسع. مثل بيتكوين، تعاني إيثيريوم من الخلل المتمثل في أن كل معاملة تحتاج إلى المعالجة بواسطة كل عقدة في الشبكة. مع بيتكوين، يبلغ حجم سلسلة الكتل الحالية حوالي 15 GB، وتنمو بحوالي 1 MB في الساعة. إذا كانت شبكة بيتكوين ستعالج 2000 معاملة في الثانية الخاصة بـ Visa، فسوف تنمو بمقدار 1 MB كل ثلاث ثوانٍ (1 GB في الساعة، 8 TB في السنة). من المرجح أن تعاني إيثيريوم من نمط نمو مماثل، ويزداد الأمر سوءًا بسبب حقيقة أنه سيكون هناك العديد من التطبيقات فوق سلسلة كتل إيثيريوم بدلاً من مجرد عملة كما هو الحال مع بيتكوين، ولكن يتم تخفيفه من خلال حقيقة أن العقد الكاملة لإيثيريوم تحتاج إلى تخزين الحالة فقط بدلاً من تاريخ سلسلة الكتل بأكمله.

تكمن المشكلة في حجم سلسلة الكتل الكبير هذا في خطر المركزية. إذا زاد حجم سلسلة الكتل إلى، لنقل، 100 TB، فإن السيناريو المحتمل هو أن عددًا صغيرًا جدًا فقط من الشركات الكبيرة سيُشغِّل عقدًا كاملة، مع استخدام جميع المستخدمين العاديين لعقد SPV خفيفة. في مثل هذه الحالة، ينشأ القلق المحتمل من أن العقد الكاملة يمكن أن تتحد معًا وتتفق جميعها على الغش بطريقة مربحة (على سبيل المثال، تغيير مكافأة الكتلة، وإعطاء أنفسهم BTC). لن يكون لدى العقد الخفيفة أي طريقة لاكتشاف ذلك على الفور. بالطبع، من المحتمل أن توجد عقدة كاملة صادقة واحدة على الأقل، وبعد بضع ساعات ستتسرب معلومات حول الاحتيال من خلال قنوات مثل ريديت (Reddit)، ولكن في تلك المرحلة سيكون الأوان قد فات: سيكون الأمر متروكًا للمستخدمين العاديين لتنظيم جهد لإدراج الكتل المعنية في القائمة السوداء، وهي مشكلة تنسيق ضخمة ومن المحتمل أن تكون غير قابلة للتنفيذ على نطاق مماثل لنطاق تنفيذ هجوم 51% ناجح. في حالة بيتكوين، يمثل هذا مشكلة حاليًا، ولكن يوجد تعديل على سلسلة الكتل اقترحه بيتر تود (opens in a new tab) والذي سيخفف من هذه المشكلة.

على المدى القريب، ستستخدم إيثيريوم استراتيجيتين إضافيتين للتعامل مع هذه المشكلة. أولاً، بسبب خوارزميات التعدين القائمة على سلسلة الكتل، سيُجبر كل مُعَدِّن على الأقل على أن يكون عقدة كاملة، مما يخلق حدًا أدنى لعدد العقد الكاملة. ثانيًا والأهم من ذلك، مع ذلك، سنقوم بتضمين جذر شجرة حالة وسيطة في سلسلة الكتل بعد معالجة كل معاملة. حتى لو كان تدقيق الكتلة مركزيًا، طالما توجد عقدة تحقق صادقة واحدة، يمكن التحايل على مشكلة المركزية عبر بروتوكول تحقق. إذا نشر مُعَدِّن كتلة غير صالحة، فيجب أن تكون تلك الكتلة إما منسقة بشكل سيئ، أو أن الحالة S[n] غير صحيحة. نظرًا لأنه من المعروف أن S[0] صحيحة، يجب أن تكون هناك بعض الحالة الأولى S[i] غير صحيحة حيث تكون S[i-1] صحيحة. ستوفر عقدة التحقق المؤشر i، إلى جانب "إثبات عدم الصلاحية" الذي يتكون من مجموعة فرعية من عقد شجرة باتريشيا (Patricia tree) التي تحتاج إلى معالجة APPLY(S[i-1],TX[i]) -> S[i]. ستتمكن العقد من استخدام تلك العقد لتشغيل هذا الجزء من الحساب، ومعرفة أن S[i] التي تم إنشاؤها لا تتطابق مع S[i] المقدمة.

هجوم آخر، أكثر تعقيدًا، سيتضمن قيام المُعَدِّنين الخبثاء بنشر كتل غير مكتملة، لذلك لا توجد حتى المعلومات الكاملة لتحديد ما إذا كانت الكتل صالحة أم لا. الحل لذلك هو بروتوكول التحدي والاستجابة (challenge-response): تُصدر عقد التحقق "تحديات" في شكل مؤشرات المعاملات المستهدفة، وعند تلقي عقدة، تتعامل العقدة الخفيفة مع الكتلة على أنها غير موثوقة حتى توفر عقدة أخرى، سواء كانت المُعَدِّن أو متحقق آخر، مجموعة فرعية من عقد باتريشيا كإثبات للصلاحية.

الخاتمة

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

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

ملاحظات وقراءات إضافية

ملاحظات

1. قد يلاحظ القارئ المتمرس أن عنوان بيتكوين في الواقع هو تجزئة للمفتاح العام للمنحنى الإهليلجي، وليس المفتاح العام نفسه. ومع ذلك، فإنه من المصطلحات المشروعة تمامًا في علم التشفير الإشارة إلى تجزئة المفتاح العام على أنها مفتاح عام بحد ذاتها. ويرجع ذلك إلى أنه يمكن اعتبار علم التشفير الخاص ببيتكوين بمثابة خوارزمية توقيع رقمي مخصصة، حيث يتكون المفتاح العام من تجزئة المفتاح العام لـ ECC، ويتكون التوقيع من المفتاح العام لـ ECC مقترنًا بتوقيع ECC، وتتضمن خوارزمية التحقق فحص المفتاح العام لـ ECC في التوقيع مقابل تجزئة المفتاح العام لـ ECC المقدمة كمفتاح عام، ثم التحقق من توقيع ECC مقابل المفتاح العام لـ ECC.
2. من الناحية الفنية، هو وسيط الكتل الـ 11 السابقة.
3. داخليًا، يعتبر كل من 2 و"CHARLIE" أرقامًا، حيث يكون الأخير بتمثيل الأساس 256 في نظام النهاية الكبرى. يمكن أن تكون الأرقام على الأقل 0 وعلى الأكثر 2²⁵⁶-1.

قراءات إضافية

1. القيمة الجوهرية (opens in a new tab)
2. الملكية الذكية (opens in a new tab)
3. العقود الذكية (opens in a new tab)
4. B-money (opens in a new tab)
5. إثباتات العمل القابلة لإعادة الاستخدام (opens in a new tab)
6. سندات الملكية الآمنة مع سلطة المالك (opens in a new tab)
7. الورقة البيضاء لبيتكوين (opens in a new tab)
8. Namecoin (opens in a new tab)
9. مثلث زوكو (opens in a new tab)
10. الورقة البيضاء للعملات الملونة (opens in a new tab)
11. الورقة البيضاء لـ Mastercoin (opens in a new tab)
12. الشركات المستقلة اللامركزية، مجلة بيتكوين (opens in a new tab)
13. التحقق المبسط من الدفع (opens in a new tab)
14. أشجار ميركل (opens in a new tab)
15. أشجار باتريشيا (opens in a new tab)
16. GHOST (opens in a new tab)
17. StorJ والوكلاء المستقلون، جيف جارزيك (opens in a new tab)
18. مايك هيرن يتحدث عن الملكية الذكية في مهرجان تورينج (opens in a new tab)
19. RLP في إيثيريوم
20. أشجار ميركل باتريشيا في إيثيريوم
21. بيتر تود يتحدث عن أشجار مجموع ميركل (opens in a new tab)

للاطلاع على تاريخ الورقة البيضاء، راجع موقع الويكي هذا (opens in a new tab).

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