دليل استخدام إيثريوم

نُشرت هذه الورقة التمهيدية في الأصل عام 2014 بواسطة فيتاليك بوتيرين، مؤسس إيثريوم، قبل إطلاق المشروع في عام 2015. والجدير بالذكر أن إيثيريوم قد تطور كثيرا منذ نشأته كحال العديد من مشاريع البرمجيات ذات المصدر المفتوح والتي يقودها المجتمع البرمجي.

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

ينبغي للباحثين والأكاديميين الذين يبحثون عن نسخة تاريخية أو أساسية من دليل الاستخدام [من ديسمبر 2014] استخدام ملف PDF هذا.

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

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

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

التاريخ

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

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

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

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

APPLY(S,TX) -> S' أو ERROR

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

APPLY({ Alice: $50, Bob: $50 },"ارسل 20 دولار من أليس إلى Bob") = { Alice: $30, Bob: $70 }

لكن؟

APPLY({ Alice: $50, Bob: $50 },"ارسل 70 دولار من أليس إلى بوب") = 

"الحالة" في البيتكوين هي مجموعة جميع العملات (تقنياً، "مخرجات المعاملات غير المنفقة" أو UTXO) التي تم تعدينها ولم يتم إنفاقها بعد، حيث يحتوي كل UTXO على فئة ومالك (يُعرَّف بعنوان من 20 بايت وهو أساساً مفتاح تشفير عام^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، وتكون المالكة هي أليس نفسها.

التنقيب

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

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

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

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

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

عند الهدف الحالي البالغ ~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 كأصل ولكن مع المعاملة الجديدة بدلاً من القديمة. لأن بيانات الكتلة مختلفة، فإن هذا يتطلب إعادة إثبات العمل. علاوة على ذلك، فإن نسخة المهاجم الجديدة من الكتلة 270000 لها تجزئة (هاش) مختلف، لذا فإن الكتل الأصلية من 270001 إلى 270005 لا "تشير" إليها؛ وبالتالي، فإن السلسلة الأصلية وسلسلة المهاجم الجديدة منفصلتان تمامًا. القاعدة هي أنه في حالة الانقسام، تعتبر سلسلة الكتل الأطول هي الحقيقة، ولذلك سيعمل المُعدِّنون الشرعيون على السلسلة 270005 بينما يعمل المهاجم وحده على السلسلة 270000. لكي يجعل المهاجم سلسلة الكتل الخاصة به هي الأطول، سيحتاج إلى قوة حاسوبية أكبر من بقية الشبكة مجتمعة من أجل اللحاق بالركب (ومن هنا جاء مصطلح "هجوم 51٪").

أشجار ميركل

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

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

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

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

تطبيقات بلوك تشين البديلة

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

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

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

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

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

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

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

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

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

إيثريوم

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

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

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

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

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

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

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

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

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

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

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

الرسائل

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

• مرسل الرسالة (ضمنيًا)
• متلقي الرسالة
• كمية الايثر التي يجب نقلها مع الرسالة
• حقل بيانات اختياري
• قيمة STARTGAS

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

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

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

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

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

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

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

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

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

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

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

تنفيذ النص البرمجي

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

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

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

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

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

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

1. تحقق مما إذا كانت الكتلة السابقة المشار إليها موجودة وصالحة.
2. تأكد من أن الطابع الزمني للكتلة أكبر من الطابع الزمني للكتلة السابقة المشار إليها وأقل من 15 دقيقة في المستقبل
3. تأكد من صحة رَقْم الكتلة والصعوبة وجذر المعاملة وجذر العم وحد الغاز (مفاهيم مختلفة منخفضة المستوى خاصة بـ إيثريوم).
4. تأكد من صحة إثبات العمل الموجود على الكتلة.
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. تحقق مما إذا كان جذر شجرة Merkle للحالة S_FINAL يساوي جذر الحالة النهائية المقدم في ترويسة الكتلة. إذا كان الأمر كذلك، فإن الكتلة صالحة؛ وإلا فهي غير صالحة.

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

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

التطبيقات

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

أنظمة الرموز

تحتوي أنظمة الرموز الموجودة على blockchain على العديد من التطبيقات التي تتراوح من العملات الفرعية التي تمثل أصولًا مثل الدولار الأمريكي أو الذهب إلى أسهم الشركات، والرموز الفردية التي تمثل الممتلكات الذكية، والقسائم الآمنة غير القابلة للتزوير، وحتى أنظمة الرموز التي لا ترتبط بالقيمة التقليدية على الإطلاق، والتي تستخدم كأنظمة نقاط للتحفيز. من المدهش أن أنظمة الرموز سهلة التنفيذ في إيثريوم. النقطة الأساسية التي يجب فهمها هي أن العملة، أو نظام الرموز، في الأساس، هي عبارالنقطة الأساسية التي يجب فهمها هي أن العملة، أو نظام الرموز، في الأساس، هي عبارة عن قاعدة بيانات بعملية واحدة: طرح X وحدات من A وإعطاء X وحدات إلى B، بشرط (i) أن يكون لدى A على الأقل X وحدات قبل المعاملة و(2) أن تتم الموافقة على المعاملة من قبل A. كل ما يتطلبه الأمر لتنفيذ نظام الرموز هو تنفيذ هذا المنطق في عقد. ة عن قاعدة بيانات بعملية واحدة: طرح X وحدات من A وإعطاء X وحدات إلى B، بشرط (i) أن يكون لدى 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

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

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

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

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

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

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

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

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

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

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

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

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

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

The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". يعمل هذا العقد على النحو التالي. أولاً، يتم تقسيم البيانات المطلوبة إلى كتل، وتشفير كل كتلة لتحقيق الخصوصية، وبناء شجرة ميركل منها. بعد ذلك، يتم إنشاء عقد بقاعدة مفادها أنه في كل N كتلة، سيختار العقد فهرسًا عشوائيًا في شجرة ميركل (باستخدام تجزئة الكتلة السابقة، التي يمكن الوصول إليها من كود العقد، كمصدر للعشوائية)، ويعطي X إيثر للكيان الأول لتزويد المعاملة بإثبات مبسط للتحقق من الدفع لملكية الكتلة عند هذا الفهرس المحدد في الشجرة. عندما يريد المستخدم إعادة تنزيل ملفه، يمكنه استخدام بروتوكول قناة الدفع المصغر (على سبيل المثال، دفع 1 szabo لكل 32 كيلوبايت) لاستعادة الملف؛ والنهج الأكثر فعالية من حيث الرسوم هو عدم قيام الدافع بنشر المعاملة حتى النهاية، واستبدال المعاملة بدلاً من ذلك بأخرى أكثر ربحية قليلاً بنفس nonce بعد كل 32 كيلوبايت.

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

المنظمات اللامركزية ذاتية الحوكمة

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

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

• [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 من إيثريوم غير متزامنة - حيث يمكن لطرفين تسجيل توقيعاتهما على blockchain في أوقات مختلفة وسيقوم التوقيع الأخير بإرسال المعاملة تلقائيًا.

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

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

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

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

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

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

بروتوكول "الشجرة الفرعية الأكثر ثقلًا والجشع الملحوظ" (GHOST) هو ابتكار تم تقديمه لأول مرة من قبل يوناتان سومبولينسكي وأفيف زوهار في ديسمبر 2013 (opens in a new tab). الدافع وراء GHOST هو أن سلاسل الكتل ذات أوقات التأكيد السريعة تعاني حاليًا من انخفاض الأمان بسبب معدل التخلف المرتفع - لأن الكتل تستغرق وقتًا معينًا للانتشار عبر الشبكة، إذا قام المعدن A بتعدين كتلة ثم حدث أن قام المعدن B بتعدين كتلة أخرى قبل أن تنتشر كتلة المعدن A إلى B، فإن كتلة المعدن B ستضيع ولن تساهم في أمان الشبكة. علاوة على ذلك، هناك مشكلة مركزية: إذا كان المعدن أ عبارة عن تجمع تعدين بقوة تجزئة 30% وكان لدى ب قوة تجزئة 10%، فسيكون لدى أ خطر إنتاج كتلة قديمة 70% من الوقت (نظرًا لأن أ أنتج الكتلة الأخيرة في 30% من الوقت الآخر، وبالتالي سيحصل على بيانات التعدين على الفور) بينما سيكون لدى ب خطر إنتاج كتلة قديمة 90% من الوقت. وبالتالي، إذا كانت فترة الكتلة قصيرة بما يكفي ليكون معدل التآكل مرتفعًا، فسوف تكون A أكثر كفاءة بشكل كبير ببساطة بسبب حجمها. مع الجمع بين هذين التأثيرين، فإن سلاسل الكتل التي تنتج الكتل بسرعة من المرجح جدًا أن تؤدي إلى حصول مجموعة تعدين واحدة على نسبة كبيرة بما يكفي من قوة تجزئة الشبكة للحصول على سيطرة فعلية على عملية التعدين.

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

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

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

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

الرسوم

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

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

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-complete؛ وهذا يعني أن كود EVM يمكنه ترميز أي عملية حسابية يمكن تنفيذها، بما في ذلك الحلقات اللانهائية. يسمح كود EVM بالتكرار بطريقتين. أولاً، هناك تعليمة JUMP التي تسمح للبرنامج بالقفز مرة أخرى إلى مكان سابق في النص البرمجي، وتعليمة JUMPI للقيام بالقفز الشرطي، مما يسمح بعبارات مثل while x < 27: x = x * 2. ثانيًا، يمكن للعقود استدعاء عقود أخرى، مما يسمح بالتكرار. يؤدي هذا بطبيعة الحال إلى مشكلة: هل يمكن للمستخدمين الضارين إغلاق عمال المناجم والعقد بالكامل عن طريق إجبارهم على الدخول في حلقة لا نهائية؟ تنشأ هذه المشكلة بسبب مشكلة في علوم الكمبيوتر تُعرف باسم مشكلة التوقف: لا توجد طريقة لمعرفة، في الحالة العامة، ما إذا كان برنامج معين سيتوقف أم لا.

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

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

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

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (تشغيل خطوة واحدة من البرنامج وتسجيل التغيير في التخزين)

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

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

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

• 1: وي
• 10¹²: szabo
• 10¹⁵: فيني
• 10¹⁸: الأثير

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

وسيكون نموذج الإصدار على النحو التالي:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الخلاصة

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

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

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

ملاحظات

1. قد يلاحظ القارئ المتمرس أن عنوان البيتكوين في الواقع هو تجزئة المفتاح العام المنحنى الإهليلجي، وليس المفتاح العام نفسه. ومع ذلك، فإن المصطلحات التشفيرية المشروعة تمامًا هي الإشارة إلى تجزئة المفتاح العام باعتباره مفتاحًا عامًا في حد ذاته. يرجع ذلك إلى أنه يمكن اعتبار تشفير بيتكوين بمثابة خوارزمية توقيع رقمي مخصصة، حيث يتكون المفتاح العام من تجزئة المفتاح العام ECC، ويتكون التوقيع من المفتاح العام ECC المتصل بتوقيع ECC، وتتضمن خوارزمية التحقق التحقق من المفتاح العام ECC في التوقيع مقابل تجزئة المفتاح العام ECC المقدمة كمفتاح عام ثم التحقق من توقيع ECC مقابل المفتاح العام ECC.
2. من الناحية الفنية، هو المتوسط ​​​​للكتل الـ11 السابقة.
3. داخليًا، 2 و"CHARLIE" كلاهما أرقام^fn3، مع وجود الأخير في تمثيل القاعدة 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. نيم كوين (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).

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