هل سبق لك أن أردت معرفة المزيد حول كيفية عمل مجموعة التحديثات؟ النظرية جيدة ، لكن الخبرة العملية هي الأفضل دائما. لسوء الحظ ، لا تجعل المشاريع الحالية دائما من السهل رؤية ما يجري. لهذا السبب أنشأنا BYOR (بناء مجموعة التحديثات الخاصة بك). إنه تجميع سيادي مع الحد الأدنى من الوظائف ، مع التركيز على جعل الكود سهل القراءة والفهم.
دافعنا لهذا المشروع هو أن يفهم الناس ، من الخارج والداخل على حد سواء ، بشكل أفضل ما تفعله عمليات التجميع من حولنا بالفعل. يمكنك اللعب على BYOR المنتشر من Holesky أو قراءة شفرة المصدر على GitHub.
ما هو BYOR؟
مشروع BYOR هو نسخة مبسطة من مجموعة التحديثات السيادية. على النقيض من البراهين المتفائلة والمعرفة الصفرية لعمليات التجميع ، فإن عمليات التجميع السيادية لا تتحقق من صحة جذور الدولة على Ethereum وتعتمد فقط على توفر البيانات والإجماع على Ethereum. هذا يمنع جسور تقليل الثقة بين L1 و BYOR ، ولكنه يبسط الكود إلى حد كبير وهو مثالي للأغراض التعليمية.
تتكون قاعدة البيانات من ثلاثة برامج: العقود الذكية والعقد والمحافظ. عند نشرها معا ، فإنها تسمح للمستخدمين النهائيين بالتفاعل مع الشبكة. ومن المثير للاهتمام ، يتم تحديد حالة الشبكة بالكامل من خلال البيانات على السلسلة ، مما يعني أنه يمكن تشغيل عقد متعددة بالفعل. يمكن لكل عقدة أيضا نشر البيانات بشكل مستقل كجهاز تسلسل.
فيما يلي القائمة الكاملة للميزات التي تم تنفيذها في BYOR:
فرز الرسوم
حالة النشر إلى L1 والحصول على الحالة من L1
تجاهل المعاملات غير الصالحة
التحقق من رصيد الحساب
إرسال المعاملات
تحقق من حالة المعاملة
استخدم المحفظة
في تطبيق المحفظة ، يعمل كواجهة أمامية للشبكة ، حيث يمكن للمستخدمين إرسال المعاملات والتحقق من حالة حساباتهم أو حالة المعاملات. في الصفحة المقصودة ، سترى نظرة عامة توفر بعض الإحصائيات حول الحالة الحالية لمجموعة التحديثات ، متبوعة بحالة حسابك. على الأرجح ، لا يوجد سوى زر واحد للاتصال بالمحفظة التي تختارها وهناك أخبار حول صنبور الرمز المميز. أدناه ، يوجد شريط بحث حيث يمكنك لصق عنوان شخص ما أو تجزئة المعاملة لاستكشاف الحالة الحالية ل L2. أخيرا ، هناك قائمتان من المعاملات: الأولى هي قائمة المعاملات في مجموعة L2 ، والثانية هي قائمة المعاملات المنشورة على L1.
للبدء ، استخدم زر WalletConnect لتوصيل محفظتك. بمجرد الاتصال ، قد تتلقى إشعارا بأن محفظتك متصلة بشبكة خاطئة. إذا كان التطبيق الخاص بك يدعم تبديل الشبكة، فانقر فوق الزر تبديل الشبكة للتبديل إلى شبكة اختبار Holesky. خلاف ذلك ، قم بالتبديل يدويا.
يمكنك الآن إرسال الرموز المميزة إلى شخص ما من خلال تقديم عنوان المستلم وعدد الرموز المميزة المراد إرسالها والرسوم المطلوبة. بمجرد إرسالها ، سيطالبك تطبيق المحفظة بتوقيع الرسالة. إذا تم التوقيع بنجاح، يتم إرسال الرسالة إلى تجمع ذاكرة عقدة L2، في انتظار نشرها إلى L1. قد يختلف الوقت الذي يستغرقه تجميع المعاملة في إصدار دفعي. كل 10 ثوان ، تتحقق عقدة L2 من المحتوى المراد نشره. يتم إرسال المعاملات ذات الرسوم الأعلى أولا ، لذلك إذا حددت رسوما أقل وكان لديك الكثير من حركة المعاملات ، فقد تواجه أوقات انتظار طويلة.
تم تصميم كود BYOR ليسهل فهمه من خلال النظر إلى قاعدة التعليمات البرمجية. لا تتردد في استكشاف قاعدة التعليمات البرمجية الخاصة بنا! اقرأ أولا * README.md * ، لفهم هيكل المشروع ، يرجى قراءة ملف * ARCHITECTURE.md *.
فيما يلي بعض النقاط البارزة المثيرة للاهتمام من الكود:
مدخلات العقد {
الحدث BatchAppended(مرسل العنوان) ؛
وظيفة appendBatch (بايت calldata) خارجي {
تتطلب (msg.sender == tx.origin) ؛
تنبعث منها دفعة ملحقة (msg.sender) ؛
}
}
هذا هو العقد الذكي الوحيد المطلوب. اسمها مشتق من حقيقة أن المدخلات يتم تخزينها في وظائف انتقال الحالة. الغرض الوحيد من هذا العقد هو تخزين جميع المعاملات بسهولة. يتم نشر الدفعة المتسلسلة لهذا العقد الذكي كبيانات استدعاء، وتصدر حدثا ملحقا بالدفعة بعنوان ناشر الدفعة. بينما يمكننا تصميم النظام بحيث ينشر المعاملات مباشرة إلى EOA بدلا من العقود ، يمكن جلب البيانات بسهولة عبر JSON-RPC عن طريق إصدار الأحداث. الشرط الوحيد لهذا العقد الذكي هو أنه لا ينبغي استدعاؤه من عقد ذكي آخر ، ولكن مباشرة من EOA.
مخطط قاعدة البيانات
إنشاء حسابات جدول (
نص العنوان المفتاح الأساسي ليس فارغا ،
عدد صحيح الرصيد الافتراضي 0 غير فارغ ،
nonce عدد صحيح الافتراضي 0 NOT NULL
);
إنشاء حركات جدول (
عدد صحيح للمعرف،
من النص ليس فارغا ،
إلى نص ليس فارغا ،
قيمة عدد صحيح ليس فارغا ،
عدد صحيح ليس فارغا ،
عدد صحيح للرسوم ليس فارغا ،
نص المستلمة ليس فارغا ،
l1تاريخ التقديم عدد صحيح ليس فارغا ،
نص التجزئة غير فارغ
المفتاح الأساسي (من ، لا شيء)
);
يحتوي هذا الجدول على صف واحد
إنشاء جدول جلب الدول (
chainId عدد صحيح المفتاح الأساسي ليس فارغا ،
lastFetchedBlock عدد صحيح افتراضي 0 NOT NULL
);
هذا هو مخطط قاعدة البيانات بالكامل المستخدم لتخزين معلومات حول مجموعة التحديثات. قد تتساءل لماذا نحتاج إلى قاعدة بيانات عندما يتم تخزين جميع البيانات الضرورية على L1. في حين أن هذا صحيح ، فإن تخزين البيانات محليا يمكن أن يوفر الوقت والموارد عن طريق تجنب عمليات الاستحواذ المكررة. تعامل مع جميع البيانات المخزنة في هذا المخطط كمذكرات للحالة وتجزئات المعاملات وغيرها من المعلومات المحسوبة.
يتم استخدام جدول fetcherStates لتتبع الكتلة الأخيرة التي جلبناها عند البحث عن حدث BatchAppended. هذا مفيد عند إيقاف تشغيل العقدة وإعادة تشغيلها ؛ يعرف مكان استئناف البحث.
تقع الوظائف الموضحة أعلاه في قلب آلية انتقال الدولة في BYOR. يفترض أنه يمكن تنفيذ المعاملة بأمان ، مع عدم وجود رصيد صحيح وكاف لإجراء الدفع المحدد. بسبب هذا الافتراض ، لا توجد خطوات لمعالجة الأخطاء أو التحقق من الصحة داخل هذه الوظيفة. بدلا من ذلك، يتم تنفيذ هذه الخطوات قبل استدعاء الدالة. يتم تخزين كل حالة حساب في خريطة. إذا لم يكن الحساب موجودا بالفعل في هذا التعيين ، تعيينه إلى القيمة الافتراضية المرئية أعلى قائمة التعليمات البرمجية. من بين الحسابات الثلاثة المستخدمة ، يتم تحديث nonce ويتم تخصيص الرصيد.
توقيع المعاملات
توقيع المعاملة: نستخدم معيار EIP-712 لتوقيع البيانات المكتوبة. يتيح لنا ذلك أن نظهر للمستخدمين بوضوح ما يوقعون عليه. كما هو موضح أعلاه ، عند إرسال معاملة ، يمكننا عرض المستلم والمبلغ والرسوم بطريقة سهلة الاستخدام.
للحصول على الحدث الجديد، نقوم باسترداد جميع أحداث BatchAppended من آخر كتلة تم جلبها من عقد المدخلات. الحد الأقصى لعدد الأحداث التي نستردها هو أحدث جزء أو آخر جزء تم جلبه بالإضافة إلى حد حجم الدفعة. بعد استرداد جميع الأحداث ، نقوم باستخراج بيانات الاتصال والطابع الزمني وعنوان الناشر من كل معاملة. قم بتحديث الكتلة الأخيرة التي نحضرها إلى الكتلة الأخيرة التي نحضرها. ثم يتم تجميع بيانات المكالمة المستخرجة والطابع الزمني والناشر معا وإعادتها من الوظيفة لمزيد من المعالجة.
mempool هو كائن يدير مجموعة من المعاملات الموقعة. الجانب الأكثر إثارة للاهتمام هو كيفية تحديد الترتيب الذي يتم به ترحيل المعاملات إلى L1. كما هو موضح في الكود أعلاه ، يتم فرز المعاملات وفقا لرسومها. يسمح هذا لمتوسط سعر الرسوم في النظام بالتقلب بناء على النشاط على السلسلة.
حتى إذا حددت رسوما عالية ، فلا تزال المعاملات بحاجة إلى إنتاج حالة صالحة إذا كانت بحاجة إلى إلحاقها بالحالة الحالية. لذلك ، لا يمكنك إرسال معاملات غير صالحة لمجرد ارتفاع الرسوم.
هل تقوم BYOR حقا بتوسيع نطاق Ethereum؟
لقد بنى التفاؤل و ZK rollup أنظمة لإثبات أن جذور الدولة المنشورة تتوافق مع وظائف انتقال الدولة والبيانات التي تلتزم بها ، لكن عمليات التجميع السيادية لا تفعل ذلك. لذلك ، قد يبدو عدم قدرة هذا النوع من الإظهار على توسيع نطاق Ethereum غير بديهي في البداية. ومع ذلك ، يصبح هذا معقولا عندما ندرك أن الأنواع الأخرى من التراكمات يمكنها استخدام L1 فقط لإثبات صحة جذر الحالة المنشور. لتمييز ما إذا كانت بيانات التجميع السيادي صحيحة أم لا ، نحتاج إلى تشغيل عقدة L1 جنبا إلى جنب مع برنامج إضافي لإضفاء الطابع الرسمي على عقدة L2 لأداء وظائف انتقال الحالة ، وبالتالي زيادة الحمل الحسابي.
النظرة المستقبلية
كان بناء هذا المشروع تجربة تعليمية رائعة بالنسبة لنا ، ونأمل أن تجد جهودنا قيمة أيضا. نأمل في العودة إلى BYOR في المستقبل وإضافة نظام مقاوم للاحتيال إليها. هذا سيجعلها مجموعة متفائلة حقا ومرة أخرى درسا في الأعمال الداخلية للأنظمة التي نستخدمها كل يوم.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
بناء التراكمي الخاص بك - قائمة بمشاريع BYOR
تجميع: خطة ترجمة دنلينك
هل سبق لك أن أردت معرفة المزيد حول كيفية عمل مجموعة التحديثات؟ النظرية جيدة ، لكن الخبرة العملية هي الأفضل دائما. لسوء الحظ ، لا تجعل المشاريع الحالية دائما من السهل رؤية ما يجري. لهذا السبب أنشأنا BYOR (بناء مجموعة التحديثات الخاصة بك). إنه تجميع سيادي مع الحد الأدنى من الوظائف ، مع التركيز على جعل الكود سهل القراءة والفهم.
دافعنا لهذا المشروع هو أن يفهم الناس ، من الخارج والداخل على حد سواء ، بشكل أفضل ما تفعله عمليات التجميع من حولنا بالفعل. يمكنك اللعب على BYOR المنتشر من Holesky أو قراءة شفرة المصدر على GitHub.
ما هو BYOR؟
مشروع BYOR هو نسخة مبسطة من مجموعة التحديثات السيادية. على النقيض من البراهين المتفائلة والمعرفة الصفرية لعمليات التجميع ، فإن عمليات التجميع السيادية لا تتحقق من صحة جذور الدولة على Ethereum وتعتمد فقط على توفر البيانات والإجماع على Ethereum. هذا يمنع جسور تقليل الثقة بين L1 و BYOR ، ولكنه يبسط الكود إلى حد كبير وهو مثالي للأغراض التعليمية.
تتكون قاعدة البيانات من ثلاثة برامج: العقود الذكية والعقد والمحافظ. عند نشرها معا ، فإنها تسمح للمستخدمين النهائيين بالتفاعل مع الشبكة. ومن المثير للاهتمام ، يتم تحديد حالة الشبكة بالكامل من خلال البيانات على السلسلة ، مما يعني أنه يمكن تشغيل عقد متعددة بالفعل. يمكن لكل عقدة أيضا نشر البيانات بشكل مستقل كجهاز تسلسل.
فيما يلي القائمة الكاملة للميزات التي تم تنفيذها في BYOR:
استخدم المحفظة
في تطبيق المحفظة ، يعمل كواجهة أمامية للشبكة ، حيث يمكن للمستخدمين إرسال المعاملات والتحقق من حالة حساباتهم أو حالة المعاملات. في الصفحة المقصودة ، سترى نظرة عامة توفر بعض الإحصائيات حول الحالة الحالية لمجموعة التحديثات ، متبوعة بحالة حسابك. على الأرجح ، لا يوجد سوى زر واحد للاتصال بالمحفظة التي تختارها وهناك أخبار حول صنبور الرمز المميز. أدناه ، يوجد شريط بحث حيث يمكنك لصق عنوان شخص ما أو تجزئة المعاملة لاستكشاف الحالة الحالية ل L2. أخيرا ، هناك قائمتان من المعاملات: الأولى هي قائمة المعاملات في مجموعة L2 ، والثانية هي قائمة المعاملات المنشورة على L1.
للبدء ، استخدم زر WalletConnect لتوصيل محفظتك. بمجرد الاتصال ، قد تتلقى إشعارا بأن محفظتك متصلة بشبكة خاطئة. إذا كان التطبيق الخاص بك يدعم تبديل الشبكة، فانقر فوق الزر تبديل الشبكة للتبديل إلى شبكة اختبار Holesky. خلاف ذلك ، قم بالتبديل يدويا.
يمكنك الآن إرسال الرموز المميزة إلى شخص ما من خلال تقديم عنوان المستلم وعدد الرموز المميزة المراد إرسالها والرسوم المطلوبة. بمجرد إرسالها ، سيطالبك تطبيق المحفظة بتوقيع الرسالة. إذا تم التوقيع بنجاح، يتم إرسال الرسالة إلى تجمع ذاكرة عقدة L2، في انتظار نشرها إلى L1. قد يختلف الوقت الذي يستغرقه تجميع المعاملة في إصدار دفعي. كل 10 ثوان ، تتحقق عقدة L2 من المحتوى المراد نشره. يتم إرسال المعاملات ذات الرسوم الأعلى أولا ، لذلك إذا حددت رسوما أقل وكان لديك الكثير من حركة المعاملات ، فقد تواجه أوقات انتظار طويلة.
كيف تعمل
قمنا ببناء كل مكون باستخدام التقنيات التالية:
التنقل لأسفل في التعليمات البرمجية
تم تصميم كود BYOR ليسهل فهمه من خلال النظر إلى قاعدة التعليمات البرمجية. لا تتردد في استكشاف قاعدة التعليمات البرمجية الخاصة بنا! اقرأ أولا * README.md * ، لفهم هيكل المشروع ، يرجى قراءة ملف * ARCHITECTURE.md *.
فيما يلي بعض النقاط البارزة المثيرة للاهتمام من الكود:
العقود الذكية
معرف ترخيص SPDX: معهد ماساتشوستس للتكنولوجيا
صلابة براغما ^ 0.8.0 ؛
مدخلات العقد {
الحدث BatchAppended(مرسل العنوان) ؛
وظيفة appendBatch (بايت calldata) خارجي {
تتطلب (msg.sender == tx.origin) ؛
تنبعث منها دفعة ملحقة (msg.sender) ؛
}
}
هذا هو العقد الذكي الوحيد المطلوب. اسمها مشتق من حقيقة أن المدخلات يتم تخزينها في وظائف انتقال الحالة. الغرض الوحيد من هذا العقد هو تخزين جميع المعاملات بسهولة. يتم نشر الدفعة المتسلسلة لهذا العقد الذكي كبيانات استدعاء، وتصدر حدثا ملحقا بالدفعة بعنوان ناشر الدفعة. بينما يمكننا تصميم النظام بحيث ينشر المعاملات مباشرة إلى EOA بدلا من العقود ، يمكن جلب البيانات بسهولة عبر JSON-RPC عن طريق إصدار الأحداث. الشرط الوحيد لهذا العقد الذكي هو أنه لا ينبغي استدعاؤه من عقد ذكي آخر ، ولكن مباشرة من EOA.
مخطط قاعدة البيانات
إنشاء حسابات جدول (
نص العنوان المفتاح الأساسي ليس فارغا ،
عدد صحيح الرصيد الافتراضي 0 غير فارغ ،
nonce عدد صحيح الافتراضي 0 NOT NULL
);
إنشاء حركات جدول (
عدد صحيح للمعرف،
من النص ليس فارغا ،
إلى نص ليس فارغا ،
قيمة عدد صحيح ليس فارغا ،
عدد صحيح ليس فارغا ،
عدد صحيح للرسوم ليس فارغا ،
نص المستلمة ليس فارغا ،
l1تاريخ التقديم عدد صحيح ليس فارغا ،
نص التجزئة غير فارغ
المفتاح الأساسي (من ، لا شيء)
);
إنشاء جدول جلب الدول (
chainId عدد صحيح المفتاح الأساسي ليس فارغا ،
lastFetchedBlock عدد صحيح افتراضي 0 NOT NULL
);
هذا هو مخطط قاعدة البيانات بالكامل المستخدم لتخزين معلومات حول مجموعة التحديثات. قد تتساءل لماذا نحتاج إلى قاعدة بيانات عندما يتم تخزين جميع البيانات الضرورية على L1. في حين أن هذا صحيح ، فإن تخزين البيانات محليا يمكن أن يوفر الوقت والموارد عن طريق تجنب عمليات الاستحواذ المكررة. تعامل مع جميع البيانات المخزنة في هذا المخطط كمذكرات للحالة وتجزئات المعاملات وغيرها من المعلومات المحسوبة.
يتم استخدام جدول fetcherStates لتتبع الكتلة الأخيرة التي جلبناها عند البحث عن حدث BatchAppended. هذا مفيد عند إيقاف تشغيل العقدة وإعادة تشغيلها ؛ يعرف مكان استئناف البحث.
وظائف انتقال الدولة
const DEFAULT_ACCOUNT = { الرصيد: 0 ، لا شيء: 0 }
وظيفة uteTransaction(state, tx, feeRecipient) {
const fromAccount = getAccount (الولاية ، tx.from ، DEFAULT_ACCOUNT)
const toAccount = getAccount (الحالة ، tx.to ، DEFAULT_ACCOUNT)
الخطوة 1 تحديث nonce
منAccount.nonce = tx.nonce
الخطوة 2 نقل القيمة
منالحساب.الرصيد -= tx.value
إلىالحساب.الرصيد += tx.value
الخطوة 3 دفع الرسوم
منالحساب.الرصيد -= tx.fee
رسوم حساب المستلم.الرصيد += tx.fee
}
تقع الوظائف الموضحة أعلاه في قلب آلية انتقال الدولة في BYOR. يفترض أنه يمكن تنفيذ المعاملة بأمان ، مع عدم وجود رصيد صحيح وكاف لإجراء الدفع المحدد. بسبب هذا الافتراض ، لا توجد خطوات لمعالجة الأخطاء أو التحقق من الصحة داخل هذه الوظيفة. بدلا من ذلك، يتم تنفيذ هذه الخطوات قبل استدعاء الدالة. يتم تخزين كل حالة حساب في خريطة. إذا لم يكن الحساب موجودا بالفعل في هذا التعيين ، تعيينه إلى القيمة الافتراضية المرئية أعلى قائمة التعليمات البرمجية. من بين الحسابات الثلاثة المستخدمة ، يتم تحديث nonce ويتم تخصيص الرصيد.
توقيع المعاملات
L1 الحدث الحصول على
وظيفة getNewStates() {
const lastBatchBlock = getLastBatchBlock ()
أحداث const = getLogs (lastBatchBlock)
const calldata = getCalldata (الأحداث)
الطوابع الزمنية const = getTimestamps (الأحداث)
ملصقات const = getTransactionPosters(events)
updateLastFetchedBlock(lastBatchBlock)
إرجاع الرمز البريدي (الملصقات والطوابع الزمنية وبيانات المكالمات)
}
للحصول على الحدث الجديد، نقوم باسترداد جميع أحداث BatchAppended من آخر كتلة تم جلبها من عقد المدخلات. الحد الأقصى لعدد الأحداث التي نستردها هو أحدث جزء أو آخر جزء تم جلبه بالإضافة إلى حد حجم الدفعة. بعد استرداد جميع الأحداث ، نقوم باستخراج بيانات الاتصال والطابع الزمني وعنوان الناشر من كل معاملة. قم بتحديث الكتلة الأخيرة التي نحضرها إلى الكتلة الأخيرة التي نحضرها. ثم يتم تجميع بيانات المكالمة المستخرجة والطابع الزمني والناشر معا وإعادتها من الوظيفة لمزيد من المعالجة.
تجمعات الذاكرة وفرز تكاليفها
وظيفة popNHighestFee(txPool, n) {
txPool.sort((أ، ب) = > ب.رسوم - أ.رسوم))
إرجاع txPool.splice(0, n)
}
mempool هو كائن يدير مجموعة من المعاملات الموقعة. الجانب الأكثر إثارة للاهتمام هو كيفية تحديد الترتيب الذي يتم به ترحيل المعاملات إلى L1. كما هو موضح في الكود أعلاه ، يتم فرز المعاملات وفقا لرسومها. يسمح هذا لمتوسط سعر الرسوم في النظام بالتقلب بناء على النشاط على السلسلة.
حتى إذا حددت رسوما عالية ، فلا تزال المعاملات بحاجة إلى إنتاج حالة صالحة إذا كانت بحاجة إلى إلحاقها بالحالة الحالية. لذلك ، لا يمكنك إرسال معاملات غير صالحة لمجرد ارتفاع الرسوم.
هل تقوم BYOR حقا بتوسيع نطاق Ethereum؟
لقد بنى التفاؤل و ZK rollup أنظمة لإثبات أن جذور الدولة المنشورة تتوافق مع وظائف انتقال الدولة والبيانات التي تلتزم بها ، لكن عمليات التجميع السيادية لا تفعل ذلك. لذلك ، قد يبدو عدم قدرة هذا النوع من الإظهار على توسيع نطاق Ethereum غير بديهي في البداية. ومع ذلك ، يصبح هذا معقولا عندما ندرك أن الأنواع الأخرى من التراكمات يمكنها استخدام L1 فقط لإثبات صحة جذر الحالة المنشور. لتمييز ما إذا كانت بيانات التجميع السيادي صحيحة أم لا ، نحتاج إلى تشغيل عقدة L1 جنبا إلى جنب مع برنامج إضافي لإضفاء الطابع الرسمي على عقدة L2 لأداء وظائف انتقال الحالة ، وبالتالي زيادة الحمل الحسابي.
النظرة المستقبلية
كان بناء هذا المشروع تجربة تعليمية رائعة بالنسبة لنا ، ونأمل أن تجد جهودنا قيمة أيضا. نأمل في العودة إلى BYOR في المستقبل وإضافة نظام مقاوم للاحتيال إليها. هذا سيجعلها مجموعة متفائلة حقا ومرة أخرى درسا في الأعمال الداخلية للأنظمة التي نستخدمها كل يوم.