ملخص:

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

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

· من أجل توفير معيار أمامي لامركزي، اقترح فريق EthStorage بروتوكول الوصول web3://، الذي يوفر للمطورين مجموعة كاملة من المعايير والأدوات لنشر والوصول إلى الشفرة الأمامية من خلال العقود الذكية، وحتى أنظمة الملفات، والتي أصبحت الآن المعيار الرسمي للإيثيريوم.

· من أجل تقليل تكلفة تخزين البيانات على سلسلة الكتل Ethereum، قام فريق EthStorage بتطوير بروتوكول تخزين الطبقة الثانية EthStorage، والذي يستخدم PoRA (إثبات الوصول العشوائي) وبرهان الصفر لتقليل بشكل كبير السمات الزائدة للتخزين مع استمرارية أمان الطبقة الأولى من Ethereum.

الاعترافات: شكرًا لفاوست من GeekWeb3، وZhixiong Pan من ChainFeeds، وبروس من LXDAO، وQi Zhou، وLun Deng من EthStorage على تعليقاتهم حول هذه المقالة.

الخلفية والقضايا المتعلقة بتطبيقات DAPP اللامركزية

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

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

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

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

· خوادم الجزء الخلفي: تم تنفيذ جزء منها بواسطة العقود الذكية، وبعض المهام المكثفة حسابياً لا يمكن تنفيذها بالكامل على السلسلة.

· قاعدة البيانات: تم تنفيذها جزئيًا بواسطة العقود الذكية. نظرًا لتكاليف التخزين العالية على السلسلة، لا تزال DAPP تستخدم حلول التخزين خارج السلسلة عندما يكون حجم البيانات كبيرًا.

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

في نهاية عام 2023، قام فيتاليك بمراجعة تطوير إيثيريوم وكتب مقالًا استجابيًا للغاية “Make Ethereum Cypherpunk Again”، حيث ناقش كيف يجب على مجتمع إيثيريوم العودة إلى مفهوم السايفربانك. في المقال، خلاص القيم التي يجب على إيثيريوم وحتى مجتمع الويب3 الأكبر الالتزام بها، وأشار إلى نقطة مهمة جدًا:

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

يمكن رؤية أن فيتاليك لديه توقعات مماثلة بشأن كيفية بناء التطبيقات اللامركزية. فيما يلي، سنحلل بالتفصيل المشاكل التي تواجه كل مكون في التطبيقات اللامركزية ونستكشف كيفية تحسينها.

خدمات الواجهة الأمامية واسم النطاق

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

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

أيضًا، يرجى تخيل، إذا لم يعد فريق تطوير Uniswap يدفع لخوادم الواجهة الأمامية وخدمات اسم النطاق الخاص بهم يومًا ما، كيف سيستخدم مستخدمو Uniswap وLPs Uniswap؟

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

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

خادم الخلفية

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

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

قاعدة البيانات

بالنسبة لقواعد البيانات، يدعم EVM أصلاً أزواج مفتاح-قيمة/KV storage (Key Value Store)، والتي يمكن أن تغطي مجموعة واسعة من سيناريوهات الاستخدام، ولكن المشكلة الأساسية هي: تكلفة تخزين البيانات على السلسلة هي مرتفعة جدًا.

ما مدى تكلفتها؟ عندما يكون سعر الغاز 10 جيجاواط، يُستغرق أكثر من 6،200 إيثريوم لتخزين 1 غيغابايت من البيانات على السلسلة، وهو أكثر من 20 مليون دولار أمريكي! من الواضح أن تكاليف التخزين أصبحت القضية المركزية لتمزيق قواعد البيانات.

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

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

حل غير قابل للثقة لتطبيقات القرار

حول كيفية جعل DAPP معتمدًا تمامًا على Ethereum لنشره والوصول إليه، اقترح فريق EthStorage حلولًا اثنتين:

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

بروتوكول الوصول web3://

يمكن فهم web3:// على أنه النسخة اللامركزية من http://. على غرار عنوان URL http الذي يصل إلى الموارد المركزية عن طريق تحديد عنوان IP للخادم أو اسم النطاق، يجب على عنوان URL web3 تحديد عنوان عقد ذكي أو اسم نطاق ENS للوصول إلى الموارد المخزنة عليه.

يمكننا نشر الجزء الأمامي بالكامل من موقع الويب في عقد ذكي والوصول إليه من خلال web3://! يمكنك مقارنة الفرق بين الاثنين:

حاليًا أصبح web3:// المعيار الرسمي لإيثريوم (ERC-4804). إذا كنت ترغب في معرفة المزيد حول محتوى بروتوكول الوصول web3:// ، يمكنك زيارة موقعه الرسمي. ومن أجل إدارة الملفات بشكل أفضل في العقود الذكية ، قمنا بتقديم ERC-5018 ، الذي يحاكي مجموعة من واجهات نظام الملفات في العقود الذكية ، بحيث يمكنك تحميل مجلد كود الواجهة الأمامية المعبأة إلى عقد ذكي من خلال ethfs-cli ، والوصول إلى هذا الموقع عبر web3://.

إذا كنت مهتمًا، يمكنك متابعة البرنامج التعليمي لإكمال نشر تطبيق لامركزي بسيط والوصول إليه.

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

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

بروتوكول تخزين الطبقة 2 للتخزين EthStorage

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

يقوم المستخدمون بتحميل البيانات التي يتم تخزينها على الإيثيريوم من خلال BLOB لـ EIP-4844. يسجل العقد الذكي EthStorage فقط تجزئة البيانات في BLOB، مما يقلل بشكل فعال من تكاليف التخزين.

في نفس الوقت، سيقوم عقد تخزين الطبقة الثانية بتنزيل بيانات BLOB المقابلة إلى القرص المحلي، واستخدام PoRA (دليل الوصول العشوائي) و ZK لتقديم دليل التخزين إلى العقد على إيثريوم للتحقق. يحتاج العقد إلى استخدام تجزئة Blob المُسجّلة مسبقًا لتأكيد ما إذا كان الدليل ZK المُرفق بواسطة عقد التخزين يتطابق، لذا يمكن تأكيد أن عقد التخزين في الشبكة من الطبقة الثانية يخزن حقًا هذه البيانات.

العملية المحددة كما يلي:

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

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

حاليًا، حصلت EthStorage على منح Ethereum الرسمية ونشرت شبكة اختبار عامة على سيبوليا في سبتمبر. الجميع مرحب به للانضمام.

ملخص وتوقعات

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

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

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

يقوم الشبكة الاختبارية العامة EthStorage حاليًا بتنفيذ حملتها التحفيزية الثانية. يمكن لأعضاء المجتمع المهتمين متابعة الدليل لاستكمال نشر Dapp اللاقهر والوصول لأول مرة!

بيان:

1. تم استنساخ هذه المقالة من [المهووس بالتكنولوجيا ويب3], ينتمي حق النشر إلى الكاتب الأصلي [فريق EthStorage], إذا كان لديك أي اعتراض على إعادة الطبع، يرجى الاتصالفريق تعلم Gate ), سيقوم الفريق بالتعامل معه في أقرب وقت ممكن وفقا لإجراءات ذات الصلة.

2. تنويه: تعبر وجهات النظر والآراء المعبر عنها في هذه المقالة فقط عن وجهات نظر الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة الإصدارات اللغوية الأخرى للمقال بواسطة فريق Gate Learn ولم يتم ذكرها فيبوابة.ايو), قد لا يتم تكرار المقال المترجم، أو توزيعه، أو ارتكاب الاستنساخ.