Bagian 1. Analisis data voting blockchain 2019 di Duma Kota Moskow oleh alexeishch
Bagian 2. Audit paralel selama pemungutan suara Elektronik oleh CryptoTyan

Saya beruntung berpartisipasi dalam penulisan laporan tentang pemungutan suara blockchain di MHD 2019 sebagai bagian dari tim Roman Uneman, dan dalam artikel ini saya akan berbicara secara rinci tentang bagian yang terkait dengan analisis data.

Beberapa kata tentang sumber data. Awalnya, file unloading dari blockchain jatuh ke tangan saya. Kemudian, ketika saya melakukan analisis awal, saya menghubungi tim Roman Uneman, saya siapkan kesaksian para pengamat yang hadir di "TPS" dan memotret monitor dengan data pemilih.

Metrik

Saya memutuskan untuk melihat segala sesuatu yang terjadi melalui mata pengembang. Pertanyaan pertama yang saya tanyakan kepada diri saya adalah: "apa yang akan saya lakukan jika saya mulai merancang sistem seperti itu?" Sistem pemungutan suara - harus merupakan sistem dengan ketersediaan tinggi, dan mengandung komponen pengamatan, dan ini bukan hanya pencatatan. Oleh karena itu, untuk mengamatinya, diharuskan memilih sejumlah jumlah yang akan berfungsi sebagai metrik. Karena sistem didasarkan pada blockchain, metrik dari blockchain itu sendiri harus menjadi bagian dari metrik ini. Salah satu metrik ini adalah waktu blok. Dugaan ini adalah awal dari keseluruhan penelitian. Di hadapanku, Medusa yang sama memperhatikan masalah, tetapi mereka hanya menganggap suara dan semuanya jauh dari jelas pada mereka.

Pertama, saya akan menjelaskan apa arti waktu blok dan mengapa Anda perlu memonitor metrik ini saat blockchain bekerja. Blok waktu, ini adalah waktu di mana blok dihitung dan ditulis. Dua nilai dapat disembunyikan di bawah nama ini: ini adalah waktu yang diharapkan untuk menghitung blok dan waktu rata-rata blok. Waktu blok yang diharapkan dalam kasus Proof of authority (PoA) dari blockchain diatur oleh parameter sistem. Waktu blok rata-rata, ini sudah waktu sebenarnya, yang dihitung sebagai berikut: jika dalam waktu T jaringan blockchain menghitung n blok, maka waktu rata-rata blok adalah T / n. Perubahan tidak normal pada metrik ini menunjukkan masalah dan memungkinkan Anda untuk segera memperbaiki masalah ini.

Mari kita lihat metrik ini, dihitung berdasarkan pengunduhan data dari blockchain. Karena saya masih seorang pengembang, bukan analis, untuk memfasilitasi pekerjaan analisis data, saya secara simultan menulis program untuk analisis, yang terus-menerus membantu saya dalam hal ini. Anda akan menemukan tautan ke kode sumbernya di akhir artikel. Selanjutnya, semua grafik sedang membongkar darinya.

Sumbu X adalah nomor blok, sumbu Y adalah waktu rata-rata.

Melihat metrik ini, kita dapat memperbaiki area operasi yang stabil dari blockchain, area dengan peningkatan tajam dalam waktu rata-rata blok (Zona 1A, 1B, 2) dan area degradasi jaringan komputer blockchain, serta area yang mencurigakan yang agak menyerupai pulsa (Zona 3).

Pertama, saya menegaskan bahwa metrik ini seharusnya ditampilkan pada monitor di TPS, sebagai itu jelas dapat dinilai berdasarkan kinerja salah satu komponen utama sistem. Kedua, saya berpendapat bahwa dari data ini, pekerjaan blockchain dihentikan. Mari kita hitung berapa kali dan berapa lama.

Kami memiliki tiga bagian dengan waktu blok mencurigakan yang disebut oleh saya "Zona 1A", "Zona 1B" dan "Zona 2". Waktu perhitungan blok untuk memblokir 2046 adalah antara 3 dan 4 detik. Untuk evaluasi, kami mengambil batas atas 4 detik dan menghitung waktu ketika blockchain dihentikan.

Deskripsi kolom tabel

1. Nomor blok start zona
2. Nomor Blok Ujung Zona
3. Jumlah blok di zona
4. Zona Waktu Mulai
5. Waktu Berakhir Zona
6. Durasi Zona
7. Perkiraan waktu ketika blockchain melakukan perhitungan berdasarkan perhitungan waktu blok 4 detik
8. Perkiraan waktu saat blockchain dinonaktifkan

Saya perhatikan bahwa saya mengambil batas atas untuk waktu blok, masing-masing, ini memberikan batas atas untuk waktu perhitungan dan batas bawah untuk waktu berhenti. Yaitu waktu berhenti nyata bahkan mungkin lebih. Yaitu total waktu untuk blockchain untuk berhenti sepenuhnya adalah sekitar 2 jam.

Zona penasaran berikutnya adalah "zona 3". Ada rekaman aneh blok dalam frekuensi dibandingkan dengan periode sebelumnya, tetapi kami akan mempertimbangkan daerah ini secara terpisah ketika kita melihat distribusi suara di antara blok.

Dan akhirnya, sejak pukul 2:20 hingga akhir pemungutan suara, kami mengamati peningkatan yang konstan dalam waktu perhitungan. Biarkan saya mengingatkan Anda bahwa kita berbicara tentang blockchain PoA dan tidak ada komplikasi operasi seperti dalam kasus ETH, ketika perilaku tersebut disebabkan oleh "bom kompleksitas" di blockchain PoW. Yaitu kami mengamati perilaku tak terduga dari metrik blockchain, yang menunjukkan degradasi sistem.

Analisis Distribusi Suara

Saya akan segera membuat reservasi bahwa saya akan seobjektif mungkin dan saya tidak akan menyentuh keanehan dalam distribusi suara di antara kandidat, dan analisis ini tidak akan dilakukan dalam konteks masing-masing kandidat. Dalam program yang saya tulis, saya meninggalkan kesempatan untuk melakukan ini kepada pihak yang berkepentingan. Pada artikel ini, saya hanya tertarik dengan kinerja sistem. Jika Anda tertarik pada keanehan ini, maka Anda harus merujuk pada laporan, di sana semuanya dijelaskan sedetail mungkin.

Distribusi suara terlihat seperti ini

Sumbu X adalah nomor blok, sumbu Y adalah jumlah suara di blok.

Seperti yang diharapkan, di zona penghentian blockchain (1A, 1B, 2), tidak ada rekaman suara, karena ini adalah zona gangguan. Tetapi zona 3 memberikan alasan untuk berpikir. Ada sejumlah kecil blok 1-3 suara, beberapa semburan 4-5 suara dan gelombang suara besar di akhir zona ini. Saya menggabungkan peristiwa-peristiwa ini berdasarkan metrik waktu blok, karena degradasi sudah terjadi setelah peristiwa-peristiwa ini, dan pencatatan blok-blok ini berjalan dalam batas yang dapat diterima. Di zona 3, tidak ada penghentian blockchain, tetapi untuk beberapa alasan data praktis tidak jatuh ke dalam blockchain.

Total durasi zona ini adalah sekitar 4 jam. Yaitu mengingat bahwa seluruh suara berlangsung 12 jam, kemudian sekitar sepertiga dari waktu, karena berbagai alasan, data tidak direkam pada blockchain.

Di area yang terkait dengan degradasi, kami melihat dengan jelas bahwa mode perekaman telah berubah dan data mulai lebih sering ditulis, tidak seperti tempat-tempat di mana blockchain bekerja secara stabil. Apa yang terhubung dengannya tidak diketahui dengan pasti, karena konfigurasi yang tepat tidak tersedia bagi kami, tetapi ada asumsi bahwa ini mungkin disebabkan oleh melimpahnya Antrian Transaksi di Paritas. Perilaku ini menimbulkan pertanyaan bagi tim yang mengintegrasikan Parity dengan backend, dan juga berbicara tentang kemungkinan teoritis kehilangan suara terkait dengan pemusnahan transaksi.

Sangat menarik bahwa jumlah suara dalam blok dibatasi hingga 100. Kami belum menemukan konstanta ini dalam kode yang diterbitkan - baik dalam pengaturan, maupun dalam kode.

Saya tidak menerima penjelasan tentang asal usul lonjakan suara setelah degradasi dimulai, pada tahap analisis ini, dan saya mencoba menemukan penjelasan dalam foto-foto data dari layar pemungutan suara yang dibuat oleh para pengamat.

Analisis data tersedia untuk pengamat

Di sini kita akan berbicara tentang data yang tersedia untuk pengamat, mereka diposisikan sebagai alternatif untuk kehadiran pengamat di TPS nyata. Foto berdasarkan yang dikumpulkan, Anda bisa dapatkan dari laporan.

Saya harus segera mengatakan bahwa saya percaya bahwa para pengamat itu sengaja tidak diberikan data sejauh mereka perlu memahami dan melacak proses yang terjadi dalam sistem.

1. Pengamat tidak melihat metrik sistem dan sebagai hasilnya bahkan tidak bisa menilai tingkat operabilitasnya secara dangkal
2. Node pemantauan blockchain tidak disediakan untuk pengamat
3. Presentasi tabular dari data tidak memungkinkan pengamat untuk mengevaluasi apa yang terjadi.

Data menampilkan 4 angka, yang pada dasarnya menunjukkan corong konversi

1. Berapa banyak orang yang pergi ke awal proses pemungutan suara
2. Berapa banyak orang yang memasukkan SMS pendaftaran
3. Berapa banyak orang yang menerima buletin
4. Berapa banyak orang yang memberikan suara

Karena ini adalah corong, keempat parameter saling terkait:

1. Anda tidak bisa mendapatkan SMS tanpa membuka halaman
2. Tidak menerima SMS tidak dapat menerima buletin
3. Anda tidak dapat memilih tanpa menerima nawala

Selain itu, perlu dicatat bahwa umur buletin adalah 15 menit. Ini berarti menerima buletin, Anda dapat memilih hanya selama 15 menit.

Sumbu X adalah waktu. Sumbu y adalah jumlah orang.

Representasi visual segera menunjukkan anomali.

Fakta-fakta dari tidak adanya kunjungan ke halaman pemungutan suara (garis hijau, garis horizontal) menunjukkan tidak dapat diaksesnya bagian depan sistem. Tingkat dasar adalah 17 plot penuh (termasuk satu plot di mana kuantitas meningkat dan kemudian menurun), masing-masing selama 15 menit. Secara total, ini sekitar 4 jam 15 menit. Interval ini sebagian tumpang tindih dengan kerusakan terkait rantai blok, dan sebagian baru (mis. 14:20 - 15:01, 15:30 - 16:15).

Selama suara yang aneh itu, entah kenapa tidak ada yang datang ke situs dan tidak ada yang masuk SMS. Saya tidak menemukan penjelasan untuk fakta ini. Yaitu dengan probabilitas tinggi lonjakan ini dikaitkan dengan beberapa jenis gangguan luar.

Selama interval 15:30 - 16:15, hanya satu parameter "SMS dimasukkan" tumbuh, tampaknya mereka menyesuaikan statistik, karena sebelum itu jumlah surat suara yang dikeluarkan lebih dari jumlah orang (garis merah) yang memasukkan SMS dengan benar. Yang tidak mungkin dari segi logika.

Tentu saja, ada kemungkinan bahwa mekanisme untuk menyajikan data kepada pengamat sama sekali tidak berfungsi, atau bekerja dengan kesalahan serius, tetapi pengakuan fakta ini pada dasarnya adalah fakta bahwa pengamat tidak diizinkan pergi ke TPS, karena selain data ini, pengamat sama sekali tidak memiliki apa pun.

Kesimpulan

Secara tradisional, ketika orang berbicara tentang sistem ketersediaan tinggi, mereka memulai percakapan dengan sembilan - 90% dari waktu sistem bekerja tanpa kesalahan. Sistem yang serius dapat memberikan pekerjaan dengan dua atau tiga sembilan (99% dan 99,9% dari waktu yang diminta oleh proses dengan benar). Dalam hal pemungutan suara di Duma Negara Moskow, pemungutan suara berlangsung sekitar 12 jam dan jumlah pemilih kurang dari 10 ribu orang. Pada saat yang sama, sistem tidak berfungsi lebih dari 4 jam. Kemudian, selama lima setengah jam, perhitungan di blockchain terdegradasi dan tidak ada yang bereaksi terhadap ini, yang menunjukkan masalah dalam arsitektur karena kurangnya pemantauan metrik. Secara pribadi, saya berpendapat bahwa, dengan karakteristik seperti itu, sistem ini bahkan tidak dapat dianggap sebagai prototipe yang berfungsi.

PS Sudah ketika saya perlahan-lahan menyiapkan artikel ini, sebuah artikel DIT muncul di Habré, di mana mereka mengklaim bahwa "Sepanjang hari, sistem pemungutan suara elektronik bekerja secara stabil, kecuali satu jam, tetapi kami dapat dengan cepat memperbaiki masalahnya." Saya sangat berharap bahwa ini terjadi di alam semesta paralel dan penulis akan diberikan Hadiah Nobel untuk penemuannya, karena metrik dan data secara langsung bertentangan dengan ini. Menurut data yang saya terima dari kenyataan ini, berikut bahwa blockchain dimatikan selama 2 jam, komponen yang terkait dengan blockchain tidak bekerja selama 4 jam, dan dari 14:20 sampai akhir pemungutan suara, jaringan komputer blockchain terus merosot, yang tidak dapat mengatasi gelombang suara aneh, yang tidak dijelaskan oleh data yang saya terima dari pengamat dari alam semesta ini.

• Isi laporan lengkap dapat ditemukan di situs web yang didedikasikan untuk pemilihan elektronik.

  
  

• Kode sumber program penganalisa dan data diunggah ke Github (.NET Core 3 / WPF) -

  
  

• Isi artikel DIT tentang arsitektur sistem