الجزء 1. تحليل 2019 بيانات التصويت blockchain في دوما مدينة موسكو من قبل alexeishch
الجزء 2. التدقيق الموازي أثناء التصويت الإلكتروني من قبل CryptoTyan

لقد كنت محظوظًا بالمشاركة في كتابة تقرير حول التصويت على blockchain في MHD 2019 كجزء من فريق Roman Uneman ، وفي هذا المقال سأتحدث بالتفصيل عن الجزء المتعلق بتحليل البيانات.

بضع كلمات عن البيانات المصدر. في البداية ، وقع ملف التفريغ من blockchain في يدي. في وقت لاحق ، عندما أجريت التحليل الأولي ، تواصلت مع فريق رومان أونيمان ، وكان لديّ تحت تصرفني شهادات المراقبين الذين كانوا حاضرين في "مركز الاقتراع" وصورت مراقبين مع بيانات التصويت.

المقاييس

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

أولاً ، سأشرح معنى وقت الحظر ولماذا تحتاج إلى مراقبة هذا المقياس أثناء عمل blockchain. وقت الكتلة ، هذا هو الوقت الذي يتم فيه حساب الكتلة وكتابتها. يمكن إخفاء قيمتين تحت هذا الاسم: هذه هي الوقت المتوقع لحساب كتلة ووقت متوسط ​​كتلة. يتم تعيين وقت الكتلة المتوقع في حالة إثبات السلطة (PoA) من blockchain بواسطة معلمات النظام. متوسط ​​وقت الكتلة ، هذا وقت حقيقي بالفعل ، ويتم حسابه على النحو التالي: إذا كانت شبكة blockchain تُحسب في الوقت المناسب كتل n ، فإن متوسط ​​وقت الكتلة هو T / n. تغيير غير طبيعي في هذا المقياس يوحي بوجود مشاكل ويسمح لك بإصلاح هذه المشكلات بسرعة.

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

المحور X هو رقم الكتلة ، والمحور Y هو متوسط ​​الوقت.

بالنظر إلى هذا المقياس ، يمكننا إصلاح مناطق التشغيل المستقر للكتلة ، ومناطق الزيادة الحادة في متوسط ​​وقت الكتلة (المناطق 1A ، 1B ، 2) ومنطقة تدهور شبكة الكمبيوتر blockchain ، بالإضافة إلى منطقة مشبوهة تشبه إلى حد ما النبض (المنطقة 3).

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

لدينا ثلاثة أقسام بها أوقات حظر مشبوهة تسمى بواسطة "Zone 1A" و "Zone 1B" و "Zone 2". كان وقت حساب الكتلة لحظر 2046 بين 3 و 4 ثوانٍ. للتقييم ، نأخذ الحد الأعلى وهو 4 ثوانٍ ونحسب الوقت الذي تم فيه إيقاف blockchain.

وصف أعمدة الجدول

1. المنطقة رقم البداية كتلة
2. رقم كتلة نهاية المنطقة
3. عدد الكتل في المنطقة
4. وقت بدء المنطقة
5. منطقة نهاية الوقت
6. مدة المنطقة
7. الوقت المقدر عند إجراء blockchain للحسابات بناءً على حساب وقت الكتلة البالغ 4 ثوانٍ
8. الوقت المقدر عندما تم تعطيل blockchain

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

المنطقة الغريبة التالية هي "المنطقة 3". هناك تسجيل غريب للكتل في التكرار مقارنة بالفترات السابقة ، لكننا سننظر في هذا المجال بشكل منفصل عندما ننظر في توزيع الأصوات بين الكتل.

وأخيرًا ، من الساعة 2:20 مساءً وحتى نهاية التصويت ، نلاحظ زيادة مستمرة في وقت الحساب. واسمحوا لي أن أذكرك بأننا نتحدث عن Pochain blockchain ولا يوجد أي تعقيد للعمليات كما في حالة ETH ، عندما كان هذا السلوك ناجم عن "قنبلة معقدة" في PoW blockchain. أي نلاحظ سلوكًا غير متوقع لقياس blockchain ، مما يشير إلى تدهور النظام.

تحليل توزيع الأصوات

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

توزيع الأصوات يشبه هذا

المحور X هو رقم الكتلة ، والمحور Y هو عدد الأصوات في الكتلة.

كما هو متوقع ، في مناطق التوقف في blockchain (1A ، 1B ، 2) ، لا توجد سجلات صوتية ، لأن هذه مناطق خطأ. ولكن منطقة 3 يعطي سببا للتفكير. هناك عدد صغير من الكتل تتكون من 1-3 أصوات ، واثنين من الانفجارات من 4 إلى 5 أصوات وزيادة هائلة من الأصوات في نهاية هذه المنطقة. قمت بدمج هذه الأحداث استنادًا إلى مقياس وقت الكتلة ، نظرًا لأن التدهور حدث بالفعل بعد هذه الأحداث ، وتسجيل هذه الكتل كان ضمن حدود مقبولة. في المنطقة 3 ، لم يكن هناك توقف blockchain ، ولكن لسبب ما لم تقع البيانات عمليًا في blockchain.

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

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

من المثير للاهتمام أن عدد الأصوات في الكتلة يقتصر على 100 صوت. لم نعثر على هذا الرقم الثابت في الكود المنشور - لا في الإعدادات ولا في الكود.

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

تحليل البيانات المتاحة للمراقبين

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

يجب أن أقول على الفور أنني أعتقد أن المراقبين لم يتم تزويدهم عمداً بالبيانات إلى الحد الذي يحتاجون إليه لفهم وتتبع العمليات التي تجري في النظام

1. لم ير المراقبون مقاييس النظام ونتيجة لذلك لم يتمكنوا حتى من تقييم درجة قابلية التشغيل بشكل سطحي
2. لم يتم توفير عقدة مراقبة Blockchain للمراقبين
3. لم يسمح العرض الجدولي للبيانات للمراقبين بتقييم ما كان يحدث.

عرضت البيانات 4 أرقام ، والتي أظهرت بشكل أساسي عملية تحويل

1. كم من الناس ذهبوا إلى بداية عملية التصويت
2. كم من الناس دخلوا رسالة التسجيل
3. كم من الناس تلقى النشرة الإخبارية
4. كم من الناس صوتوا

نظرًا لأن هذا عبارة عن مسار ، فإن جميع المعلمات الأربعة مترابطة:

1. لا يمكنك الحصول على الرسائل القصيرة دون الذهاب إلى الصفحة
2. عدم تلقي الرسائل القصيرة لا يمكن تلقي رسالة إخبارية
3. لا يمكنك التصويت دون تلقي رسالة إخبارية

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

المحور العاشر هو الوقت المناسب. محور y هو عدد الأشخاص.

التمثيل البصري يظهر على الفور الشذوذ.

تشير حقائق عدم وجود زيارات إلى صفحة التصويت (الخط الأخضر الذي يكون الخط أفقيًا) إلى عدم إمكانية الوصول إلى مقدمة النظام. الصف السفلي هو 17 قطعة كاملة (بما في ذلك قطعة واحدة حيث زادت الكمية ثم انخفضت) ، كل لمدة 15 دقيقة. في المجموع ، وهذا ما يقرب من 4 ساعات و 15 دقيقة. هذه الفواصل الزمنية تتداخل جزئيًا مع الأعطال المرتبطة بـ blockchain ، وهي جديدة جزئيًا (على سبيل المثال 14:20 - 15:01 ، 15:30 - 16:15).

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

خلال الفترة 15:30 - 16:15 ، نمت معلمة واحدة فقط "SMS دخلت" ، يبدو أنهم عدّلوا الإحصاءات ، لأنه قبل ذلك كان عدد بطاقات الاقتراع الصادرة أكثر من عدد الأشخاص (الخط الأحمر) الذين أدخلوا الرسائل القصيرة بشكل صحيح. وهو أمر مستحيل من حيث المنطق.

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

النتائج

تقليديًا ، عندما يتحدث الأشخاص عن أنظمة توفر عالية ، فإنهم يبدأون محادثة مع تسعة إلى 90٪ من الوقت الذي يعمل فيه النظام دون أخطاء. يمكن أن توفر الأنظمة الخطيرة العمل مع اثنين أو ثلاثة (99٪ و 99.9٪ من الوقت الذي يعالج فيه النظام بشكل صحيح الطلبات). في حالة التصويت في مجلس الدوما في موسكو ، استمر التصويت حوالي 12 ساعة وكان عدد الناخبين أقل من 10 آلاف شخص. في الوقت نفسه ، لم يعمل النظام لأكثر من 4 ساعات. ثم ، لمدة خمس ساعات ونصف ، تدهورت الحسابات في blockchain ولم يتفاعل أحد مع ذلك ، مما يدل على وجود مشاكل في الهندسة المعمارية بسبب عدم رصد المقاييس. شخصيا ، كان لدي رأي مفاده أنه مع مثل هذه الخصائص ، لا يمكن اعتبار هذا النظام نموذجًا أوليًا عمليًا.

ملحوظة: بالفعل عندما كنت أعد ببطء لهذه المقالة ، ظهر مقال DIT على حبري ، زعموا فيه أنه "طوال اليوم ، كان نظام التصويت الإلكتروني يعمل بثبات ، باستثناء ساعة واحدة ، لكننا تمكنا من حل المشكلة بسرعة". آمل مخلصًا أن يكون هذا قد حدث في عالم موازٍ وأن يُمنح المؤلف جائزة نوبل لاكتشافها ، لأن كل من المقاييس والبيانات تتعارض بشكل مباشر مع هذا. وفقًا للبيانات التي تلقيتها من هذا الواقع ، فإن ذلك أدى إلى إيقاف تشغيل blockchain لمدة ساعتين ، وأن المكونات المرتبطة بـ blockchain لم تعمل لمدة 4 ساعات ، ومن الساعة 14:20 حتى نهاية التصويت ، كانت شبكة الكمبيوتر blockchain تتعرض للإهانة بشكل مستمر ، والتي لم تتمكن من التغلب على زيادة غريبة في الأصوات ، والتي لم تتمكن من التعامل موضحة بالبيانات التي تلقيتها من المراقبين من هذا الكون.

• يمكن العثور على محتويات التقرير الكامل على الموقع الإلكتروني المخصص للتصويت الإلكتروني.

  
  

• يتم تحميل الكود المصدري لبرنامج المحلل والبيانات إلى جيثب (.NET Core 3 / WPF) -

  
  

• محتويات مقالة DIT على بنية النظام