التحديثات الذكية مقابل العقود الذكية

ما هو العقد الذكي ولماذا كان مطلوبًا؟

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

كانت هناك ثلاث طرق لإضافة وظائف:

1) الأكثر وضوحًا هو إدخالها في رمز blockchain نفسه ، محليًا.

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

2) إنشاء blockchain آخر بهذه الوظيفة.

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

3) تنفيذ الوظائف باستخدام الآلة الافتراضية الداخلية و opcodes.

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


لذا ، فإن الرمز الذي يتم تنفيذه بواسطة الجهاز الظاهري داخل blockchain هو ما يسمى العقد الذكي ، وهو مطلوب لتنفيذ وظائف جديدة. يمكنك تسميتها "رقعة opcode" ، لكنها لا تبيع بشكل جيد :)

ما هو التحديث الذكي؟

بالانتقال إلى العقود الذكية خلال العامين الماضيين ، يمكننا القول بوضوح أنها لم تلب التوقعات. نعم ، لم يكن ازدهار ICO ممكنًا على البيتكوين ، ولكن تقديم EVM المتقدم فقط لرموز erc20 المميزة كان أكثر من اللازم.

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

حالات المستخدم المتطورة تكاد تكون مستحيلة. ألق نظرة على github.com/raiden-network/raiden-contracts/tree/master/raiden_contracts/contracts - آلاف أسطر التعليمات البرمجية بلغة غريبة غير مادية لإدارة نظام مالي معقد. لقد رأينا العديد من الاختراقات من التكافؤ و DAO بهجمات بسيطة ، ما نوع الهجمات التي تنتظرنا على مثل هذه القاعدة البرمجية البشعة؟

لا توجد قاعدة بيانات SQL ، NoSQL غير موجود ، كما لم يتم التخطيط لقاعدة بيانات الرسم البياني. تكرار مفتاح ، كثير إلى كثير؟ ORM؟ لا شيء من هذا موجود في العقد. يعتبر الحراثة ضعيفًا جدًا بالنسبة إلى لغات البرمجة المعروفة.

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

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

إدارة Onchain = التحديثات الذكية

بعد أن سئمت من الحزن مع الصلابة ، دعنا نعود إلى عام 2012 ونستذكر الخيار الأول المهملة مع إضافة حالات المستخدم أصلاً إلى blockchain.


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

أي نفس البيض فقط في الملف الشخصي. تقرر مجموعة من الأشخاص كيفية تغيير طبقة onchain بأيديهم ، ووضع الشفرة على github ، ولا يوجد خيار أمام جميع المستخدمين سوى تنزيل رمز جديد. قالوا لنا "شوكة صلبة مجدولة ليوم الجمعة ، الترقية فورا".

في هذا الشكل ، تعتبر فكرة العقود الذكية فاشلة تمامًا - لدينا بالفعل سلطة تحدد كيفية عمل طبقة الإجماع (حساب github من ethereum) ، ما هو التجريد الإضافي وغير الفعال إذا لم نتمكن من التخلص من التحديثات للطبقة الرئيسية؟

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

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

إذا كانت لديك تحديثات ذكية ، فأنت ببساطة لا تحتاج إلى عقود ذكية. يمكن تنفيذ أي حالة مستخدم بشكل أسرع وأفضل ، مع أي قاعدة بيانات من اختيارك (SQL / NoSQL / أيا كان) ، بأي لغة برمجة (تقوم بتشغيل الكود بالفعل على مستوى الجهاز ، ولا تقتصر على أي شيء). الحرية الكاملة ، مطروحًا منه 95٪ من النفقات العامة التي أنفقتها على الصلابة ، ولا نحتاج إلى نحت blockchain جديد كحل # 2.

هناك نوعان من السلبيات للتحديثات الذكية

1. الآن ، لن تتم المصادقة على كل حالة مستخدم من قِبل المصدقين ، نظرًا لأنهم يفكرون ويصوتون لنوع التصحيح الذي سيكون مفيدًا للشبكة (ويقطعون الأبواب الخلفية الخبيثة بصراحة). من غير المحتمل أن تتم الموافقة على أشياء مثل العملات المشفرة من قبل الأغلبية (نسبة 67٪ أو 95٪ ، يتم تكوينها داخل الشبكة نفسها)

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

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

الملخص

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

المستقبل هو للتحديثات الذكية ، وتقريباً جميع البلوكتشين التي يتم تطويرها حاليًا تتضمنها منذ البداية (tezos ، dfinity ، polkadot ، decred ، tendermint ، fairlayer ، إلخ). حتى في العقود الذكية نفسها ، فإنهم يحاولون الآن تشغيل آلية التحديث داخل أنفسهم ، مدركين أن مفهوم التعيين في الحجر لا يعمل ، وبطريقة أو بأخرى سيكون من الضروري التحديث .

إليك ويكي أكثر تفصيلاً حول هذا الموضوع (باللغة الإنجليزية. أنا مندهش من محاولة Vitalik و Vlad Zamfir تشويه التحديثات الذكية ، حيث يجعل منافسهما المباشر EVM متقادمًا تمامًا.