باعتبارها منصة blockchain مفتوحة وقابلة للبرمجة ، فإن Ethereum ليست فقط البنية التحتية للعملة الرقمية ، ولكنها توفر أيضًا للمطورين بيئة لإنشاء تطبيقات لامركزية (DAPP) وعقود ذكية. نظرًا لمرونتها وقابليتها للتوسع ، أصبحت Ethereum لاعبًا رئيسيًا في النظام البيئي للعملات المشفرة وجذبت المطورين والمستخدمين في جميع أنحاء العالم.
في محتوى العدد الأخير من Cregis Research ، ناقشنا قيمة تجريد الحساب (AA) ، لذلك قمنا بتوسيع موضوع معقد: في يونيو ، أشار V God ، مؤسس Ethereum ، في مدونته إلى أن Ethereum تواجه حاليًا بعض التحديات والمشكلات المهمة ، يجب حل هذه المشكلات من أجل تعزيز التطوير الإضافي لـ Ethereum ، وإلا ستفشل Ethereum ، وبالتالي فإن الاتجاهات الثلاثة للتحول هي: محفظة العقد الذكية ، وحماية الخصوصية ، وتوسيع الطبقة الثانية. بعد التحول الناجح ، ستتحسن Ethereum من حيث الأداء وتجربة المستخدم وحماية الخصوصية.
بالطبع ، تجلب هذه التحولات أيضًا تحديات جديدة. تم تحليل مشاكل وأهمية محافظ العقود الذكية (CA) بوضوح في الإصدار السابق. لخص Cregis Research بعض الأسئلة المتبقية ، وحدد بعض النقاط الأساسية التي ترتبط ارتباطًا وثيقًا بتجربتك اليومية ، وأعاد النظر في وجهة نظر V God قبل نصف شهر.
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-12238ff8ff-dd1a6f-7649e1)
المشاكل الجديدة الناجمة عن التحولات الثلاثة في Ethereum
2. لماذا يجب تغيير Ethereum؟
ينبع السبب الرئيسي لضرورة تغيير Ethereum من تحديات قابلية التوسع والأمان وحماية الخصوصية.
بادئ ذي بدء ، دعونا نراجع المناقشة في العدد الأخير من Cregis Research: Cregis Research: The Archaeology of Ethereum Account Structure and the Value of Account Abstraction ، والتي ذكرت: تشغيل Ethereum في بيئة لامركزية لا يزال يواجه أكبر نقطة ألم: خطي البيئة من المستحيل إجراء معاملات عالية التزامن وتجميع الرموز المعقدة ، وهو ما يمثل تحديًا قابلية التوسع.
نظرًا لقدرة معالجة المعاملات المحدودة الحالية في Ethereum ، يمكن أن تصبح تكاليف المعاملات عالية عندما تزداد حركة مرور الشبكة. تعيق تكلفة المعاملة المرتفعة هذه تعميم Ethereum في السوق الرئيسية ، لذلك تحتاج Ethereum إلى زيادة قدرتها على المعالجة وتقليل تكاليف المعاملات من خلال توسيع L2 ، مثل التجميعات.
ثانيًا ، يعد أمان المحفظة أيضًا مسألة مهمة. تتم سرقة محافظ EOA (التي تمثلها محافظ متعددة المكونات الإضافية) التي تنشئ أزواج مفاتيح عامة-خاصة من خلال عبارات أولية بحتة في تدفق لا نهائي. من التسرب على نطاق واسع لعناوين ARB airdrop إلى Twitter KOL الذي يبكي أن المحفظة قد أفرغت بواسطة كثف المتسللون والمستخدمون الفرديون بشكل متزايد مطالبهم بأمان الأصول. وفي الوقت نفسه غير مستعدين للتضحية بتجربة المستخدم (سيختار مستخدمو المؤسسات حل MPC مستضاف ذاتيًا بالكامل لأمن الأصول ، وهم على استعداد للتضحية براحة التشغيل على السلسلة التفاعل) ، والذي يتطلب من Ethereum تغيير أمان المحفظة وتعزيز محافظ العقود الذكية. توفر أحدث معايير أمان الصناعة (مثل EIP-4337) أمانًا وراحة أقوى للمستخدمين الفرديين.
أخيرًا ، تمثل حماية الخصوصية تحديًا رئيسيًا آخر. جميع المعاملات على Ethereum L1 عامة لأن EOA مرتبط بالأصول ؛ سواء كان مستخدمًا فرديًا عاديًا أو حيتان عملاقة أو مؤسسات شركة ، فقد يعانون حاليًا من ضائقة عناوين الأصول التي يتم تمييزها وتعقبها. لذلك ، تحتاج Ethereum إلى مزيد من التحسين لتنفيذ حسابات الخصوصية غير الخبيثة لضمان أنه ليس فقط الأصول الموجودة في السلسلة ، ولكن أيضًا معلومات DID مثل الهويات وأنظمة الائتمان على السلسلة يمكن حمايتها في المستقبل ؛ يمكن أن تضمن آلية المواجهة أن الجناة لا يمكنهم الهروب من التتبع وصرف الأموال بسلاسة.
ثلاثة ، أهم 3 أسئلة (ملخصة ومضافة تعليقات بواسطة Cregis Research)
كيف يدير المستخدمون عناوين محفظة متعددة
بالمقارنة مع Web 3.0 ، يتمتع Web 2.0 بنفس الميزة التي لا تزال قائمة: يمكن للمستخدمين استخدام ميزة اجتماعية (عنوان البريد الإلكتروني ، ورقم الهاتف المحمول ، وما إلى ذلك) لإنشاء حسابات تطبيقات مختلفة ، على الرغم من أنه في عالم Web 3.0 ، فإن عناوين السلسلة العامة مع نفس آلية الإجماع يمكن استخدامها (على سبيل المثال: BSC و ERC-20 و TRC-20) ، ولكن مع ظهور خطة التوسيع L 2 ، سيكون لدى المستخدمين عدة عناوين L 2 مختلفة تمامًا وطبقة 1 وطبقة مختلفة قد تستخدم شبكتان لغات برمجة مختلفة ومكونات وسيطة ، مما يؤدي إلى مشاكل في حجز العنوان ؛ وقبل بيئة التجسير متعددة السلاسل التي يمثلها Polkadot أو بيئة L2 متعددة الأغراض للأغراض العامة المذكورة في رؤية Cregis المستقبلية ، يمكن للمستخدمين أيضًا تحتاج إلى إدارة العديد من عناوين السلاسل غير المتجانسة ، مما يزيد من تعقيد إدارة العناوين.
أخيرًا ، فإن اقتراح العنوان الخفي لحماية الخصوصية ، إذا تم استخدامه على نطاق واسع ، سيسمح للمستخدمين بالحصول على المزيد من العناوين لتعزيز حماية خصوصيتهم. لذلك ، يصبح حجز عنوان أكثر صعوبة.
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-6ff8e67a5e-dd1a6f-7649e1)
كيف يدرك المستخدمون الدفع غير المرئي؟ (خاصة في بيئة متعددة العناوين)
بافتراض أن L2 في النظام البيئي Ethereum يتطور كما هو متوقع في المستقبل ، حتى إذا كانت معظم الأصول الأصلية عبارة عن رموز ERC-20 ، فقد يكون لدى المستخدمين عناوين L2 متعددة ، ويصبح اختيار العنوان الصحيح لإرسال الأصول أو الدفع أكثر تعقيدًا. تقليديًا ، يحتاج المستخدمون فقط إلى معرفة عنوان الطرف الآخر لإرسال دفعة ، لكنهم الآن بحاجة إلى معرفة شبكات الطبقة الثانية والعناوين المقابلة التي يقبلها الطرف الآخر ، ويطلبون خطوات إضافية لضمان إرسال الأموال إلى الوجهة الصحيحة.
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-abadccb42e-dd1a6f-7649e1)
** مشكلة الدفع الخفي متعدد الحسابات في بيئة L 2 **
على الرغم من أن حساب العقد (CA) الذي تم إنشاؤه باستخدام العقود الذكية يمكن أن يحل مشكلة العنونة بسهولة ، إلا أنه لا يمكنه توفير وظيفة حماية الخصوصية بشكل مباشر.
اقترح Vitalik حلاً لحماية الخصوصية في الأيام الأولى من Ethereum: عنوان التخفي. يمكن أن تساعدك عناوين التخفي في الحفاظ على الخصوصية عند إجراء معاملات العملات الرقمية دون أن يتعقبها الآخرون. بعد ذلك ، سيشارك Cregis بعض الخطوات لحل مشكلات الخصوصية:
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-4164370ab2-dd1a6f-7649e1)
(سير العمل الكامل لعنوان التخفي)
العنوان الخفي هو عنوان يمكن إنشاؤه بواسطة المرسل أو المستفيد ، ولكن يتحكم فيه المدفوع لأمره فقط. يمكن لهذا النوع من العناوين تحسين خصوصية Ethereum في سيناريوهات مختلفة. في هذا الوضع ، ينشئ Bob (المستفيد) مفتاح استهلاك ويستخدم هذا المفتاح لإنشاء عنوان تعريف غير مرئي: B، h = hash (x). يقوم بتمرير عنوان التعريف هذا إلى أليس (الدافع). يمكن لأليس إجراء عملية حسابية على عنوان التعريف هذا ، مما يؤدي إلى إنشاء عنوان التخفي الذي يخص أليس لبوب: b-1. يمكنها بعد ذلك إرسال أي أصول تريدها إلى هذا العنوان وسيكون لـ Bob السيطرة الكاملة عليها.
تحتاج عملية إنشاء عنوان التسلل إلى تشغيل وظيفة المنحنى الإهليلجي: يولد بوب مفتاح m ، ويحسب M = G \ * m ، حيث G هي نقطة توليد عامة لمنحنى ناقص. تنشئ Alice مفتاحًا مؤقتًا r وتنشر المفتاح العام المؤقت R = G \ * r. يمكن لـ Alice حساب سر مشترك S = M \ * r ، ويمكن لـ Bob حساب نفس السر المشترك S = m \ * R.
بعد عنوان Bob المتخفي: يتم إنشاء b-1 ، عندما يكون من الضروري التداول مع Alice ، تقوم Alice بإنشاء قيمة: c ، وتنشر بيانات مشفرة لـ c لا يستطيع سوى Bob فك تشفيرها ؛ عند تنفيذ المعاملة ، يتم التحقق منها بواسطة إثبات عدم المعرفة: يوفر Bob القيمة x التي قدمتها Alice والقيمة c المقدمة من Alice يمكن أن تجعل k = التجزئة (التجزئة (x) ، c) ، وتكتمل المعاملة بعد أن يكون التحقق صحيحًا. نظرًا لأن عنوان Bob الأصلي لم يتم الكشف عنه أثناء هذه العملية ، ولم يتم توفير سوى القيمة المشفرة x ، فإن إثبات المعرفة الصفرية مسؤول فقط عن التحقق من محتوى k ، ولن يُظهر العلاقة بين B و b-1.
كيف يحمي منتج المحفظة أصول المستخدم وخصوصيته في نفس الوقت؟
في بيئة السلسلة التقليدية ، تهتم المحافظ بشكل أساسي بحماية المفاتيح الخاصة ، ولكن في عالم ZKP (إثبات المعرفة الصفرية) ، تحتاج المحافظ إلى حماية بيانات اعتماد المصادقة وبيانات المستخدم. مثال على ذلك هو ZKpass ، وهو نظام هوية يعتمد على ZK-SNARK و MPC ، والذي يسمح للمستخدمين بإنشاء أدلة أساسية للتحقق من الهوية ، وفي نفس الوقت يقوم بعملية التحقق من الهوية دون تقديم أي معلومات حقيقية من خلال MPC.
ومع ذلك ، نظرًا لأن علامة البيانات المشفرة (جزء المفتاح) نفسها تحل محل المفتاح الخاص لـ EOA ، يصبح الاحتفاظ بعلامة البيانات المشفرة أكثر إشكالية ، حيث يحتاج المستخدمون إلى إجراء مفاضلة بين الاحتفاظ بالبيانات محليًا أو الاعتماد على طرف ثالث احتفظ بنسخة مشفرة. في الوقت نفسه ، تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفتاح التشفير لضمان التوازن بين الأمان وسهولة الاستخدام. لذلك ، في المستقبل المنظور ، سيكون لاستراتيجيات الأمان للمحافظ على مستوى المؤسسة والمحافظ الشخصية اتجاهات مختلفة تمامًا. وبأخذ المحافظ على مستوى المؤسسة كمثال ، يحتاج مستخدمو المحافظ على مستوى المؤسسة إلى بيئة أمنية أكثر صرامة لحماية الأموال. هناك احتمال كبير للتخلي عن: 1. محافظ العقد التي قد تحتوي على نقاط ضعف بشرية ؛ 2. محافظ MPC مختلطة مع مخاطر الطرف الثالث ، اختر محافظ MPC المخصخصة بنفس مستوى الأمان مثل محافظ الأجهزة ؛ في بعض السيناريوهات ، لأنك تريد دائمًا للحصول على أفضل انطباع للمستخدم ، يمكنك اختيار منتج به بعض العمليات المركزية.
بالإضافة إلى ذلك ، لا يفي عنوان blockchain بمتطلبات التحقق من الهوية في البيئة ، لذلك يتم قبول حلول ENS (اسم مجال blockchain) و SBT (رمز ربط الروح) تدريجيًا من قبل الجمهور ، ولكن لا تزال هناك مشكلات لم يتم حلها. تم حله: الأول من الصعب حل مشكلة الأسماء المكررة التي أحدثها العالم التقليدي.على الرغم من أن الأخير لا يعاني من مشكلة الأسماء المكررة ، إلا أنه لا توجد تطبيقات بيئية كافية للاستفادة الكاملة من وظائف اضطراب الشخصية الانفصامية التي يحملها ، و حتى سيناريوهات التطبيق الحالية يمكن القول أنها ضعيفة للغاية.
4. ملخص
أعتقد أن الجميع يفهم بالفعل أن المحفظة ليست سوى جزء مهم من موضوع [تحويل Ethereum] الذي ظل مستعراً في دائرة العملة العالمية لما يقرب من 3 أشهر. لا يقتصر طموح V God على تحقيق طموح "Ethereum يكمل عيوب Bitcoin" ، ولكنه يأمل أيضًا في أن يتمكن Ethereum حقًا من إنشاء عالم يمكن للجميع الدخول إليه ، وهو مرتبط بشكل كبير بالعالم الحقيقي ، ويحتفظ بمفهوم اللامركزية.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
ملاحظة بحث Cregis: المشكلات الجديدة التي تسببها ثلاثة تحولات في Ethereum
I. مقدمة
في محتوى العدد الأخير من Cregis Research ، ناقشنا قيمة تجريد الحساب (AA) ، لذلك قمنا بتوسيع موضوع معقد: في يونيو ، أشار V God ، مؤسس Ethereum ، في مدونته إلى أن Ethereum تواجه حاليًا بعض التحديات والمشكلات المهمة ، يجب حل هذه المشكلات من أجل تعزيز التطوير الإضافي لـ Ethereum ، وإلا ستفشل Ethereum ، وبالتالي فإن الاتجاهات الثلاثة للتحول هي: محفظة العقد الذكية ، وحماية الخصوصية ، وتوسيع الطبقة الثانية. بعد التحول الناجح ، ستتحسن Ethereum من حيث الأداء وتجربة المستخدم وحماية الخصوصية.
بالطبع ، تجلب هذه التحولات أيضًا تحديات جديدة. تم تحليل مشاكل وأهمية محافظ العقود الذكية (CA) بوضوح في الإصدار السابق. لخص Cregis Research بعض الأسئلة المتبقية ، وحدد بعض النقاط الأساسية التي ترتبط ارتباطًا وثيقًا بتجربتك اليومية ، وأعاد النظر في وجهة نظر V God قبل نصف شهر.
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-12238ff8ff-dd1a6f-7649e1)
المشاكل الجديدة الناجمة عن التحولات الثلاثة في Ethereum
2. لماذا يجب تغيير Ethereum؟
ينبع السبب الرئيسي لضرورة تغيير Ethereum من تحديات قابلية التوسع والأمان وحماية الخصوصية.
بادئ ذي بدء ، دعونا نراجع المناقشة في العدد الأخير من Cregis Research: Cregis Research: The Archaeology of Ethereum Account Structure and the Value of Account Abstraction ، والتي ذكرت: تشغيل Ethereum في بيئة لامركزية لا يزال يواجه أكبر نقطة ألم: خطي البيئة من المستحيل إجراء معاملات عالية التزامن وتجميع الرموز المعقدة ، وهو ما يمثل تحديًا قابلية التوسع.
نظرًا لقدرة معالجة المعاملات المحدودة الحالية في Ethereum ، يمكن أن تصبح تكاليف المعاملات عالية عندما تزداد حركة مرور الشبكة. تعيق تكلفة المعاملة المرتفعة هذه تعميم Ethereum في السوق الرئيسية ، لذلك تحتاج Ethereum إلى زيادة قدرتها على المعالجة وتقليل تكاليف المعاملات من خلال توسيع L2 ، مثل التجميعات.
ثانيًا ، يعد أمان المحفظة أيضًا مسألة مهمة. تتم سرقة محافظ EOA (التي تمثلها محافظ متعددة المكونات الإضافية) التي تنشئ أزواج مفاتيح عامة-خاصة من خلال عبارات أولية بحتة في تدفق لا نهائي. من التسرب على نطاق واسع لعناوين ARB airdrop إلى Twitter KOL الذي يبكي أن المحفظة قد أفرغت بواسطة كثف المتسللون والمستخدمون الفرديون بشكل متزايد مطالبهم بأمان الأصول. وفي الوقت نفسه غير مستعدين للتضحية بتجربة المستخدم (سيختار مستخدمو المؤسسات حل MPC مستضاف ذاتيًا بالكامل لأمن الأصول ، وهم على استعداد للتضحية براحة التشغيل على السلسلة التفاعل) ، والذي يتطلب من Ethereum تغيير أمان المحفظة وتعزيز محافظ العقود الذكية. توفر أحدث معايير أمان الصناعة (مثل EIP-4337) أمانًا وراحة أقوى للمستخدمين الفرديين.
أخيرًا ، تمثل حماية الخصوصية تحديًا رئيسيًا آخر. جميع المعاملات على Ethereum L1 عامة لأن EOA مرتبط بالأصول ؛ سواء كان مستخدمًا فرديًا عاديًا أو حيتان عملاقة أو مؤسسات شركة ، فقد يعانون حاليًا من ضائقة عناوين الأصول التي يتم تمييزها وتعقبها. لذلك ، تحتاج Ethereum إلى مزيد من التحسين لتنفيذ حسابات الخصوصية غير الخبيثة لضمان أنه ليس فقط الأصول الموجودة في السلسلة ، ولكن أيضًا معلومات DID مثل الهويات وأنظمة الائتمان على السلسلة يمكن حمايتها في المستقبل ؛ يمكن أن تضمن آلية المواجهة أن الجناة لا يمكنهم الهروب من التتبع وصرف الأموال بسلاسة.
ثلاثة ، أهم 3 أسئلة (ملخصة ومضافة تعليقات بواسطة Cregis Research)
كيف يدير المستخدمون عناوين محفظة متعددة
بالمقارنة مع Web 3.0 ، يتمتع Web 2.0 بنفس الميزة التي لا تزال قائمة: يمكن للمستخدمين استخدام ميزة اجتماعية (عنوان البريد الإلكتروني ، ورقم الهاتف المحمول ، وما إلى ذلك) لإنشاء حسابات تطبيقات مختلفة ، على الرغم من أنه في عالم Web 3.0 ، فإن عناوين السلسلة العامة مع نفس آلية الإجماع يمكن استخدامها (على سبيل المثال: BSC و ERC-20 و TRC-20) ، ولكن مع ظهور خطة التوسيع L 2 ، سيكون لدى المستخدمين عدة عناوين L 2 مختلفة تمامًا وطبقة 1 وطبقة مختلفة قد تستخدم شبكتان لغات برمجة مختلفة ومكونات وسيطة ، مما يؤدي إلى مشاكل في حجز العنوان ؛ وقبل بيئة التجسير متعددة السلاسل التي يمثلها Polkadot أو بيئة L2 متعددة الأغراض للأغراض العامة المذكورة في رؤية Cregis المستقبلية ، يمكن للمستخدمين أيضًا تحتاج إلى إدارة العديد من عناوين السلاسل غير المتجانسة ، مما يزيد من تعقيد إدارة العناوين.
أخيرًا ، فإن اقتراح العنوان الخفي لحماية الخصوصية ، إذا تم استخدامه على نطاق واسع ، سيسمح للمستخدمين بالحصول على المزيد من العناوين لتعزيز حماية خصوصيتهم. لذلك ، يصبح حجز عنوان أكثر صعوبة.
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-6ff8e67a5e-dd1a6f-7649e1)
كيف يدرك المستخدمون الدفع غير المرئي؟ (خاصة في بيئة متعددة العناوين)
بافتراض أن L2 في النظام البيئي Ethereum يتطور كما هو متوقع في المستقبل ، حتى إذا كانت معظم الأصول الأصلية عبارة عن رموز ERC-20 ، فقد يكون لدى المستخدمين عناوين L2 متعددة ، ويصبح اختيار العنوان الصحيح لإرسال الأصول أو الدفع أكثر تعقيدًا. تقليديًا ، يحتاج المستخدمون فقط إلى معرفة عنوان الطرف الآخر لإرسال دفعة ، لكنهم الآن بحاجة إلى معرفة شبكات الطبقة الثانية والعناوين المقابلة التي يقبلها الطرف الآخر ، ويطلبون خطوات إضافية لضمان إرسال الأموال إلى الوجهة الصحيحة.
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-abadccb42e-dd1a6f-7649e1)
** مشكلة الدفع الخفي متعدد الحسابات في بيئة L 2 **
على الرغم من أن حساب العقد (CA) الذي تم إنشاؤه باستخدام العقود الذكية يمكن أن يحل مشكلة العنونة بسهولة ، إلا أنه لا يمكنه توفير وظيفة حماية الخصوصية بشكل مباشر.
اقترح Vitalik حلاً لحماية الخصوصية في الأيام الأولى من Ethereum: عنوان التخفي. يمكن أن تساعدك عناوين التخفي في الحفاظ على الخصوصية عند إجراء معاملات العملات الرقمية دون أن يتعقبها الآخرون. بعد ذلك ، سيشارك Cregis بعض الخطوات لحل مشكلات الخصوصية:
! [Cregis Research Observation: New Issues from Three Transformations of Ethereum] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-4164370ab2-dd1a6f-7649e1)
(سير العمل الكامل لعنوان التخفي)
العنوان الخفي هو عنوان يمكن إنشاؤه بواسطة المرسل أو المستفيد ، ولكن يتحكم فيه المدفوع لأمره فقط. يمكن لهذا النوع من العناوين تحسين خصوصية Ethereum في سيناريوهات مختلفة. في هذا الوضع ، ينشئ Bob (المستفيد) مفتاح استهلاك ويستخدم هذا المفتاح لإنشاء عنوان تعريف غير مرئي: B، h = hash (x). يقوم بتمرير عنوان التعريف هذا إلى أليس (الدافع). يمكن لأليس إجراء عملية حسابية على عنوان التعريف هذا ، مما يؤدي إلى إنشاء عنوان التخفي الذي يخص أليس لبوب: b-1. يمكنها بعد ذلك إرسال أي أصول تريدها إلى هذا العنوان وسيكون لـ Bob السيطرة الكاملة عليها.
تحتاج عملية إنشاء عنوان التسلل إلى تشغيل وظيفة المنحنى الإهليلجي: يولد بوب مفتاح m ، ويحسب M = G \ * m ، حيث G هي نقطة توليد عامة لمنحنى ناقص. تنشئ Alice مفتاحًا مؤقتًا r وتنشر المفتاح العام المؤقت R = G \ * r. يمكن لـ Alice حساب سر مشترك S = M \ * r ، ويمكن لـ Bob حساب نفس السر المشترك S = m \ * R.
بعد عنوان Bob المتخفي: يتم إنشاء b-1 ، عندما يكون من الضروري التداول مع Alice ، تقوم Alice بإنشاء قيمة: c ، وتنشر بيانات مشفرة لـ c لا يستطيع سوى Bob فك تشفيرها ؛ عند تنفيذ المعاملة ، يتم التحقق منها بواسطة إثبات عدم المعرفة: يوفر Bob القيمة x التي قدمتها Alice والقيمة c المقدمة من Alice يمكن أن تجعل k = التجزئة (التجزئة (x) ، c) ، وتكتمل المعاملة بعد أن يكون التحقق صحيحًا. نظرًا لأن عنوان Bob الأصلي لم يتم الكشف عنه أثناء هذه العملية ، ولم يتم توفير سوى القيمة المشفرة x ، فإن إثبات المعرفة الصفرية مسؤول فقط عن التحقق من محتوى k ، ولن يُظهر العلاقة بين B و b-1.
كيف يحمي منتج المحفظة أصول المستخدم وخصوصيته في نفس الوقت؟
في بيئة السلسلة التقليدية ، تهتم المحافظ بشكل أساسي بحماية المفاتيح الخاصة ، ولكن في عالم ZKP (إثبات المعرفة الصفرية) ، تحتاج المحافظ إلى حماية بيانات اعتماد المصادقة وبيانات المستخدم. مثال على ذلك هو ZKpass ، وهو نظام هوية يعتمد على ZK-SNARK و MPC ، والذي يسمح للمستخدمين بإنشاء أدلة أساسية للتحقق من الهوية ، وفي نفس الوقت يقوم بعملية التحقق من الهوية دون تقديم أي معلومات حقيقية من خلال MPC.
ومع ذلك ، نظرًا لأن علامة البيانات المشفرة (جزء المفتاح) نفسها تحل محل المفتاح الخاص لـ EOA ، يصبح الاحتفاظ بعلامة البيانات المشفرة أكثر إشكالية ، حيث يحتاج المستخدمون إلى إجراء مفاضلة بين الاحتفاظ بالبيانات محليًا أو الاعتماد على طرف ثالث احتفظ بنسخة مشفرة. في الوقت نفسه ، تحتاج المحافظ التي تدعم التعافي الاجتماعي إلى إدارة استرداد الأصول واسترداد مفتاح التشفير لضمان التوازن بين الأمان وسهولة الاستخدام. لذلك ، في المستقبل المنظور ، سيكون لاستراتيجيات الأمان للمحافظ على مستوى المؤسسة والمحافظ الشخصية اتجاهات مختلفة تمامًا. وبأخذ المحافظ على مستوى المؤسسة كمثال ، يحتاج مستخدمو المحافظ على مستوى المؤسسة إلى بيئة أمنية أكثر صرامة لحماية الأموال. هناك احتمال كبير للتخلي عن: 1. محافظ العقد التي قد تحتوي على نقاط ضعف بشرية ؛ 2. محافظ MPC مختلطة مع مخاطر الطرف الثالث ، اختر محافظ MPC المخصخصة بنفس مستوى الأمان مثل محافظ الأجهزة ؛ في بعض السيناريوهات ، لأنك تريد دائمًا للحصول على أفضل انطباع للمستخدم ، يمكنك اختيار منتج به بعض العمليات المركزية.
بالإضافة إلى ذلك ، لا يفي عنوان blockchain بمتطلبات التحقق من الهوية في البيئة ، لذلك يتم قبول حلول ENS (اسم مجال blockchain) و SBT (رمز ربط الروح) تدريجيًا من قبل الجمهور ، ولكن لا تزال هناك مشكلات لم يتم حلها. تم حله: الأول من الصعب حل مشكلة الأسماء المكررة التي أحدثها العالم التقليدي.على الرغم من أن الأخير لا يعاني من مشكلة الأسماء المكررة ، إلا أنه لا توجد تطبيقات بيئية كافية للاستفادة الكاملة من وظائف اضطراب الشخصية الانفصامية التي يحملها ، و حتى سيناريوهات التطبيق الحالية يمكن القول أنها ضعيفة للغاية.
4. ملخص
أعتقد أن الجميع يفهم بالفعل أن المحفظة ليست سوى جزء مهم من موضوع [تحويل Ethereum] الذي ظل مستعراً في دائرة العملة العالمية لما يقرب من 3 أشهر. لا يقتصر طموح V God على تحقيق طموح "Ethereum يكمل عيوب Bitcoin" ، ولكنه يأمل أيضًا في أن يتمكن Ethereum حقًا من إنشاء عالم يمكن للجميع الدخول إليه ، وهو مرتبط بشكل كبير بالعالم الحقيقي ، ويحتفظ بمفهوم اللامركزية.