يوصي Vitalik باستخدام zk-SNARKs لفصل حسابات منطق التداول عن الحسابات التي تحتفظ بالأصول. يؤدي ذلك إلى تحسين الخصوصية وتجربة المستخدم والاسترداد الاجتماعي بنقرة واحدة. يقدم الباحث في إيثريوم، توني واهرستاتر، تحليلاً مفصلاً لهذا النموذج الأولي للمحفظة، يغطي سير العمل والمزايا.
جزيل الشكر لمات على المناقشات الرائعة حول هذا الموضوع وعلى تطوير هذه الأداة لتحليل كل عقد ووضعه في شجرة Merkle المتفرقة التي تعمل على تبسيط النماذج الأولية من خلال إلغاء الحاجة إلى براهين zk على شجرة باتريشيا. أيضًا، شكرًا لـ Vitalik على مساهمته الرائعة.
يمكن أن تشكل إدارة حسابات متعددة تحديًا لعدة أسباب، بما في ذلك التعافي الاجتماعي والخصوصية واللغة الثانية ومشكلات تجربة المستخدم بشكل عام. إن استخدام عنوان خفي يجعل الأمور أكثر تعقيدًا لأن كل تفاعل يتطلب حسابًا جديدًا. يوصي Vitalik باستخدام zk-SNARKs لفصل حسابات منطق التداول عن الحسابات التي تحتفظ بالأصول. يؤدي ذلك إلى تحسين الخصوصية وتجربة المستخدم والاسترداد الاجتماعي بنقرة واحدة.
بالنسبة لما يلي، أوصي أولاً بمراجعة منشور Vitalik "التحولات الثلاثة" للحصول على بعض المعلومات الأساسية.
باختصار ما نحاول تحقيقه هو:
** التعافي الاجتماعي الشامل دون المساس بالخصوصية. **
1. الطريقة التقليدية
يبدو التنفيذ البسيط ولكن المساس بالخصوصية كما يلي:
يقدم المستخدم توقيعًا وبعض النية/الأوامر إلى حساب الاحتفاظ بالأصول.
يقوم حساب الاحتفاظ بالأصول بإعادة توجيه التوقيع إلى حساب الاحتفاظ المنطقي.
يستمد حساب الحجز المنطقي المفتاح العام من التوقيع ويقارنه بمفتاحه العام المخزن.
إذا تم اجتياز عملية التحقق، فسيقوم الحساب المنطقي بإخطار حساب الاحتفاظ بالأصول لمواصلة العملية.
يقوم حساب الأصول بتنفيذ أوامر المستخدم.
والعيب هو أن هذا يربط بشكل علني بين الحسابات المنطقية وحسابات الأصول، مما يعرض الخصوصية للخطر.
2. استخدم ZK-SNARK
باستخدام zk-SNARKs، يمكن للمستخدمين إثبات أنهم مصرح لهم بالإنفاق دون الكشف عن العلاقة بين حساب الاحتفاظ المنطقي وحساب الاحتفاظ بالأصول.
سير العمل هو كما يلي:
يقوم المستخدم ببناء شجرة ميركل محليا والتعرف على الأوراق التي تحتوي على عقده.
1.1 تحتوي شجرة Merkle بشكل أساسي على قيم الفتحة0 والفتحة1 لكل عقد موجود مرتبة حسب التاريخ أو الاسم.
1.2 يمكن لكل مستخدم إنشاء شجرة Merkle محليًا بناءً على أحدث حالة.
يقوم المستخدم بإنشاء دليل zk لإثبات أنه يعرف السر في حساب الحجز المنطقي. والدليل بالتفصيل لاحقا.
يرسل المستخدم إثبات zk إلى حساب الاحتفاظ بالأصول.
شهادة التحقق من حساب الأصول، والتي تؤكد ما يلي:
4.1 يعرف المستخدمون أين يوجد المنطق.
4.2 يعرف المستخدم قيمة سرية تم تجزئتها وتعيينها للقيمة المخزنة في حساب الحجز المنطقي.
4.3 يمكن للمستخدمين إعادة بناء حالة الحساب، جذر شجرة Merkle الذي تم الحفاظ عليه في السلسلة الأساسية (على سبيل المثال، المترجمة مسبقًا)
4.4 استخدم الأرقام العشوائية الصحيحة (المستخدمة لتبديل المفاتيح في حسابات الاحتفاظ المنطقية).
بشكل أساسي، يمكن للمستخدم أن يقول: "لدي إذن يمكن إثباته من حساب الحجز المنطقي لتنفيذ هذا الإجراء، وأعرف موقع هذا الحساب المنطقي."
ميزة
تجربة المستخدم: يمكن لمفتاح خاص واحد أو إعداد واحد متعدد التوقيع التحكم في حسابات متعددة، حتى لو كانت على مستويات L2 مختلفة.
الاستعادة: يمكن استعادة الحسابات بسهولة أكبر من خلال تحديث عقد واحد.
الخصوصية: لا توجد روابط عامة بين الحسابات.
التوافق: يساعد هذا في نشر محافظ Account Abstraction (AA) وغيرها من الميزات.
بالإضافة إلى ذلك، من خلال إضافة عقد (مجمع) آخر بين المنطق وعقد الاحتفاظ بالأصول، يمكن تقديم أدلة متعددة لحسابات الاحتفاظ بالأصول المختلفة في معاملة واحدة، مما يسمح بمعاملة الحساب تقريبًا مثل UTXO. سيتمكن المجمعون من الحصول على شهادات zk متعددة وإرسالها إلى حسابات الأصول الخاصة بهم للتحقق منها. وبطبيعة الحال، يمكن لمثل هذا المجمع إنشاء روابط - بما في ذلك الخصوصية - بين حسابات الأصول الفردية.
تجدر الإشارة إلى أنه ليس بالضرورة خيارًا بين استخدام SNARKs (وبالتالي الاعتماد على أمانها) وعدم استخدام SNARKs على الإطلاق (وبالتالي فقدان خصائص الخصوصية الجيدة). قد يكون الحل الوسط هو استخدام إثبات SNARK لفتح نافذة زمنية في عقد الحجز المنطقي، يليه تأخير قصير، وبعد ذلك يمكن لمالك عقد الحجز المنطقي تغيير قيمة الفتحة 0، بدلاً من طلب إثبات SNARK للإنفاق و وبالتالي تغيير منطق الاستهلاك. يمكن للمالك الحالي للعقد منع تحديثات بيانات الاعتماد باستخدام التأخير قبل فتح النافذة الزمنية.
تفاصيل تقنية
يتضمن إعداد zk-SNARK عناصر خاصة:
المفتاح المستخدم للتحقق.
عنوان حساب الاحتفاظ المنطقي هو العنوان الذي يشير إليه حساب الاحتفاظ بالأصول.
فرع ميركل لتحديد قيم الدولة المحددة.
رقم يسمح بتدوير المفتاح أثناء إبطال المفاتيح القديمة. لا يتم نشر العناصر الخاصة مثل عناوين العقود والأسرار الخاصة بمنطق النص العادي، ولكنها تُستخدم لربط حسابات الاحتفاظ المنطقية وحسابات الاحتفاظ بالأصول بشكل خاص. من خلال إنشاء أدلة على الولاية بأكملها، ليست هناك حاجة إلى سلطة مركزية لإنشاء شجرة ميركل لتقديم الأدلة.
1. حساب عقد منطقي
قد يبدو النموذج الأولي لحساب الحجز المنطقي كما يلي:
صلابة براغما >=0.7.0 <0.9.0؛
العقد LogicHoldingAccount قابل للامتلاك { uint256 public Slot0 = 0x1234; // سر مجزأ uint256 public nonce = 0; // تتبع التغييرات الرئيسية في عنوان المالك العام؛
وظيفة updateOwner(uint256 newValue) public OnlyOwner { nonce += 1; Slot0 = newValue;
فتحة0: المتغير العام الذي يحمل في البداية قيمة التجزئة. المالك فقط هو الذي يعرف الصورة الأولية المجزأة.
nonce: عداد يتتبع عدد تحديثات معلومات المالك. وهذا يضمن أن المفاتيح القديمة تصبح غير صالحة.
updateOwner(uint256 newValue): وظيفة تقوم بتحديث القيمة وإضافة رقم عشوائي.
يتتبع هذا العقد منطق الإنفاق الحالي للمالك (الفتحة 0) ويسمح بالتحديثات عبر وظيفة updateOwner.
2. حساب الاحتفاظ بالحساب
صلابة براغما >=0.7.0 <0.9.0؛
Contract AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;
// حجم الحقل العددي، وحجم الحقل الأساسي، وبيانات مفتاح التحقق، وما إلى ذلك. // ...
وظيفة التحقق من (uint [2] بيانات الاتصال _pA, uint [2] [2] بيانات الاتصال _pB, uint [2] بيانات الاتصال _pC, uint [2] calldata _pubSignals) إرجاع العرض العام (bool val) { // كود تجميع Snarkjs للتحقق من الإثبات... // ... }
// _pubSignals [0] - جذر العقد-slot0||nonce Merkle Tree // _pubSignals [1] - وظيفة عنوان صاحب المنطق Hased ute (العنوان المستحق لـ، مبلغ uint256، uint [2] بيانات الاتصال _pA, uint [2] [2] بيانات الاتصال _pB, uint [2] بيانات الاتصال _pC, uint [2] calldata _pubSignals) public { ContractRootPrecompile.getRoot(block.number) uint256 المحددLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "غير مسموح به");
تقوم حسابات الأصول بتخزين الأصول مثل ETH وتسمح للمستخدمين بتقديم دليل على عمليات السحب. من خلال التحقق من تطابق LogicHolder المحدد مع logicHoldingAccountHash، يمكن للمالك التأكد من أن عقد الاحتفاظ بالأصل يقبل فقط البراهين من عقد الاحتفاظ المنطقي المعتمد، بدلاً من أي عقد تعسفي.
يضمن السر المقدم كإشارة خاصة عند إنشاء الدليل أن مالك الحساب الذي يحتوي على منطق الإنفاق فقط هو الذي يمكنه الوصول إلى الأموال من حساب الاحتفاظ بالأصول.
3. الدائرة
تم تطوير الدائرة التالية باستخدام circom، ويمكن العثور على الكود الكامل هنا.
براغما سيركوم 2.0.2؛
include "./modules/merkleTree.circom";include "./modules/commitmentHasher.circom";
القالب الرئيسي (المستويات) {جذر إدخال الإشارة؛ منطق إدخال الإشارةHoldingAddressHash; منطق إدخال الإشارةHoldingAddress; سر إدخال الإشارة؛ إدخال الإشارة نونس؛ عناصر مسار إدخال الإشارة [levels] ; مسار إدخال الإشارة [levels] ; مكون SecretHasher = SecretHasher(); SecretHasher.secret <== Secret; تجزئة المكون = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== SecretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; شجرة المكونات = MerkleTreeChecker(levels); Tree.leaf <== hasher.commitment; Tree.root <== root; for ( i = 0; i <levels; i++) { Tree.pathElements [i] <== pathElements [i] ; Tree.pathIndices [i] <== pathIndices [i] ;
المكون الرئيسي {public [root,logicHoldingAddressHash]} = Main(N);
تحتوي الدائرة على إجمالي 7 إشارات، اثنتان منها عامة، وهي جذر شجرة Merkle وعنوان التجزئة لحساب الاحتفاظ المنطقي (الذي يجب تجزئته قبل تشفيره في عقد الاحتفاظ بالأصول لمنع المراقبين من تجميع الحساب) class) بناءً على نفس منطق حساب المالك).
ختاماً
في عالم حيث يجب على المستخدمين إدارة حسابات متعددة، أصبحت الحاجة إلى وظيفة التعافي الاجتماعي الشاملة ذات أهمية متزايدة. يمكن استخدام Zk-SNARK في المحافظ التي تنفذ فصل المنطق/الأصول، مما يسمح للمستخدمين باستخدام "منطق" الحساب "أ" للإنفاق من الحساب "ب" دون إنشاء رابط بين الاثنين. كخطوة أولى، يمكن استخدام إثباتات SNARK في الإجراءات الأقل خطورة من نفقات الأصول. على سبيل المثال، قد تكون نقطة البداية الجيدة هي السماح للمستخدمين ببدء "طلبات السحب". إذا لم يقم مالك عقد المنطق باعتراض، فيمكن للمستخدم إنهاء الطلب بعد فترة من الوقت.
بهذه الطريقة، لا يزال بإمكان مالك عقد الملكية المنطقي التدخل، ولو بطريقة تنتهك الخصوصية، في حالة حدوث شيء غير متوقع.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
التعافي الاجتماعي الشامل: كيف تدرك zk-SNARKs الفصل بين منطق معاملات المحفظة وأصولها؟
المؤلف الأصلي: @Toni Wahrstätter
تاريخ الإصدار: 12 سبتمبر 2023
ترجمة: معهد أبحاث ديبوكس
مقدمة
يوصي Vitalik باستخدام zk-SNARKs لفصل حسابات منطق التداول عن الحسابات التي تحتفظ بالأصول. يؤدي ذلك إلى تحسين الخصوصية وتجربة المستخدم والاسترداد الاجتماعي بنقرة واحدة. يقدم الباحث في إيثريوم، توني واهرستاتر، تحليلاً مفصلاً لهذا النموذج الأولي للمحفظة، يغطي سير العمل والمزايا.
يمكن أن تشكل إدارة حسابات متعددة تحديًا لعدة أسباب، بما في ذلك التعافي الاجتماعي والخصوصية واللغة الثانية ومشكلات تجربة المستخدم بشكل عام. إن استخدام عنوان خفي يجعل الأمور أكثر تعقيدًا لأن كل تفاعل يتطلب حسابًا جديدًا. يوصي Vitalik باستخدام zk-SNARKs لفصل حسابات منطق التداول عن الحسابات التي تحتفظ بالأصول. يؤدي ذلك إلى تحسين الخصوصية وتجربة المستخدم والاسترداد الاجتماعي بنقرة واحدة.
باختصار ما نحاول تحقيقه هو:
** التعافي الاجتماعي الشامل دون المساس بالخصوصية. **
1. الطريقة التقليدية
يبدو التنفيذ البسيط ولكن المساس بالخصوصية كما يلي:
والعيب هو أن هذا يربط بشكل علني بين الحسابات المنطقية وحسابات الأصول، مما يعرض الخصوصية للخطر.
2. استخدم ZK-SNARK
باستخدام zk-SNARKs، يمكن للمستخدمين إثبات أنهم مصرح لهم بالإنفاق دون الكشف عن العلاقة بين حساب الاحتفاظ المنطقي وحساب الاحتفاظ بالأصول.
سير العمل هو كما يلي:
1.1 تحتوي شجرة Merkle بشكل أساسي على قيم الفتحة0 والفتحة1 لكل عقد موجود مرتبة حسب التاريخ أو الاسم.
1.2 يمكن لكل مستخدم إنشاء شجرة Merkle محليًا بناءً على أحدث حالة.
يقوم المستخدم بإنشاء دليل zk لإثبات أنه يعرف السر في حساب الحجز المنطقي. والدليل بالتفصيل لاحقا.
يرسل المستخدم إثبات zk إلى حساب الاحتفاظ بالأصول.
شهادة التحقق من حساب الأصول، والتي تؤكد ما يلي:
4.1 يعرف المستخدمون أين يوجد المنطق.
4.2 يعرف المستخدم قيمة سرية تم تجزئتها وتعيينها للقيمة المخزنة في حساب الحجز المنطقي.
4.3 يمكن للمستخدمين إعادة بناء حالة الحساب، جذر شجرة Merkle الذي تم الحفاظ عليه في السلسلة الأساسية (على سبيل المثال، المترجمة مسبقًا)
4.4 استخدم الأرقام العشوائية الصحيحة (المستخدمة لتبديل المفاتيح في حسابات الاحتفاظ المنطقية).
بشكل أساسي، يمكن للمستخدم أن يقول: "لدي إذن يمكن إثباته من حساب الحجز المنطقي لتنفيذ هذا الإجراء، وأعرف موقع هذا الحساب المنطقي."
ميزة
بالإضافة إلى ذلك، من خلال إضافة عقد (مجمع) آخر بين المنطق وعقد الاحتفاظ بالأصول، يمكن تقديم أدلة متعددة لحسابات الاحتفاظ بالأصول المختلفة في معاملة واحدة، مما يسمح بمعاملة الحساب تقريبًا مثل UTXO. سيتمكن المجمعون من الحصول على شهادات zk متعددة وإرسالها إلى حسابات الأصول الخاصة بهم للتحقق منها. وبطبيعة الحال، يمكن لمثل هذا المجمع إنشاء روابط - بما في ذلك الخصوصية - بين حسابات الأصول الفردية.
تفاصيل تقنية
يتضمن إعداد zk-SNARK عناصر خاصة:
1. حساب عقد منطقي
قد يبدو النموذج الأولي لحساب الحجز المنطقي كما يلي:
صلابة براغما >=0.7.0 <0.9.0؛
العقد LogicHoldingAccount قابل للامتلاك { uint256 public Slot0 = 0x1234; // سر مجزأ uint256 public nonce = 0; // تتبع التغييرات الرئيسية في عنوان المالك العام؛
وظيفة updateOwner(uint256 newValue) public OnlyOwner { nonce += 1; Slot0 = newValue;
يتتبع هذا العقد منطق الإنفاق الحالي للمالك (الفتحة 0) ويسمح بالتحديثات عبر وظيفة updateOwner.
2. حساب الاحتفاظ بالحساب
صلابة براغما >=0.7.0 <0.9.0؛
Contract AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234...;
// حجم الحقل العددي، وحجم الحقل الأساسي، وبيانات مفتاح التحقق، وما إلى ذلك. // ...
وظيفة التحقق من (uint [2] بيانات الاتصال _pA, uint [2] [2] بيانات الاتصال _pB, uint [2] بيانات الاتصال _pC, uint [2] calldata _pubSignals) إرجاع العرض العام (bool val) { // كود تجميع Snarkjs للتحقق من الإثبات... // ... }
// _pubSignals [0] - جذر العقد-slot0||nonce Merkle Tree // _pubSignals [1] - وظيفة عنوان صاحب المنطق Hased ute (العنوان المستحق لـ، مبلغ uint256، uint [2] بيانات الاتصال _pA, uint [2] [2] بيانات الاتصال _pB, uint [2] بيانات الاتصال _pC, uint [2] calldata _pubSignals) public { ContractRootPrecompile.getRoot(block.number) uint256 المحددLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, "غير مسموح به");
bool validProof = VereProof(_pA, _pB, _pC, _pubSignals) == true; إذا (validProof) { (نجاح منطقي،) = to.call{value:amount}(""); تتطلب(النجاح); } }
تلقي () الخارجية المستحقة {
تقوم حسابات الأصول بتخزين الأصول مثل ETH وتسمح للمستخدمين بتقديم دليل على عمليات السحب. من خلال التحقق من تطابق LogicHolder المحدد مع logicHoldingAccountHash، يمكن للمالك التأكد من أن عقد الاحتفاظ بالأصل يقبل فقط البراهين من عقد الاحتفاظ المنطقي المعتمد، بدلاً من أي عقد تعسفي.
يضمن السر المقدم كإشارة خاصة عند إنشاء الدليل أن مالك الحساب الذي يحتوي على منطق الإنفاق فقط هو الذي يمكنه الوصول إلى الأموال من حساب الاحتفاظ بالأصول.
3. الدائرة
تم تطوير الدائرة التالية باستخدام circom، ويمكن العثور على الكود الكامل هنا.
براغما سيركوم 2.0.2؛
include "./modules/merkleTree.circom";include "./modules/commitmentHasher.circom";
القالب الرئيسي (المستويات) {جذر إدخال الإشارة؛ منطق إدخال الإشارةHoldingAddressHash; منطق إدخال الإشارةHoldingAddress; سر إدخال الإشارة؛ إدخال الإشارة نونس؛ عناصر مسار إدخال الإشارة [levels] ; مسار إدخال الإشارة [levels] ; مكون SecretHasher = SecretHasher(); SecretHasher.secret <== Secret; تجزئة المكون = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== SecretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; شجرة المكونات = MerkleTreeChecker(levels); Tree.leaf <== hasher.commitment; Tree.root <== root; for ( i = 0; i <levels; i++) { Tree.pathElements [i] <== pathElements [i] ; Tree.pathIndices [i] <== pathIndices [i] ;
المكون الرئيسي {public [root,logicHoldingAddressHash]} = Main(N);
تحتوي الدائرة على إجمالي 7 إشارات، اثنتان منها عامة، وهي جذر شجرة Merkle وعنوان التجزئة لحساب الاحتفاظ المنطقي (الذي يجب تجزئته قبل تشفيره في عقد الاحتفاظ بالأصول لمنع المراقبين من تجميع الحساب) class) بناءً على نفس منطق حساب المالك).
ختاماً
في عالم حيث يجب على المستخدمين إدارة حسابات متعددة، أصبحت الحاجة إلى وظيفة التعافي الاجتماعي الشاملة ذات أهمية متزايدة. يمكن استخدام Zk-SNARK في المحافظ التي تنفذ فصل المنطق/الأصول، مما يسمح للمستخدمين باستخدام "منطق" الحساب "أ" للإنفاق من الحساب "ب" دون إنشاء رابط بين الاثنين. كخطوة أولى، يمكن استخدام إثباتات SNARK في الإجراءات الأقل خطورة من نفقات الأصول. على سبيل المثال، قد تكون نقطة البداية الجيدة هي السماح للمستخدمين ببدء "طلبات السحب". إذا لم يقم مالك عقد المنطق باعتراض، فيمكن للمستخدم إنهاء الطلب بعد فترة من الوقت.
بهذه الطريقة، لا يزال بإمكان مالك عقد الملكية المنطقي التدخل، ولو بطريقة تنتهك الخصوصية، في حالة حدوث شيء غير متوقع.