Artefak control plane yang buruk, data plane yang rapuh, dan 5xx di mana-mana Postingan ini menjelaskan bagaimana kami memandang insiden seperti pemadaman Cloudflare iniArtefak control plane yang buruk, data plane yang rapuh, dan 5xx di mana-mana Postingan ini menjelaskan bagaimana kami memandang insiden seperti pemadaman Cloudflare ini

Ketika File Fitur Membuat Internet Gempar

2025/11/24 23:41

Artefak bidang kontrol yang buruk, bidang data yang rapuh, dan 5xx di mana-mana

Postingan ini menjelaskan bagaimana kami memandang insiden seperti pemadaman Cloudflare minggu ini, mengapa bidang kontrol kontrak pintar murni dengan kunci waktu mengubah mode kegagalan, dan di mana bukti zero-knowledge cocok.

Ringkasan pemadaman Selasa

Pada 18 Nov 2025 pukul 11:20 UTC, edge Cloudflare mulai mengembalikan 5xx untuk sebagian besar lalu lintas. Pemicu utamanya bukan penyerang; itu adalah perubahan izin ClickHouse yang membuat kueri mengembalikan baris duplikat. Kueri tersebut menghasilkan "file fitur" Manajemen Bot yang dikirim ke setiap kotak edge setiap beberapa menit.

Duplikat tersebut menggandakan ukuran file dan mendorong jumlah fitur melebihi 200. Modul bot memiliki batas keras dan unwrap() yang panik saat overflow. Saat node bergantian antara output "lama-baik" dan "baru-buruk" setiap lima menit, armada berosilasi sampai semua shard diperbarui dan tetap buruk.

Cloudflare menghentikan penerbit pada 14:24, mengirimkan file terakhir-yang-diketahui-baik pada 14:30, dan melaporkan pemulihan penuh pada 17:06. Tindak lanjut yang mereka sebutkan: memperkuat penyerapan konfigurasi internal, menambahkan sakelar matikan global, dan meninjau mode kegagalan di seluruh modul.

Lihat postmortem Cloudflare sendiri untuk timeline lengkap dan cuplikan kode.

Ada dua masalah terpisah dalam cerita tersebut:

  1. Kegagalan bidang kontrol: generator mengeluarkan artefak di luar spesifikasi (duplikat, terlalu banyak fitur, terlalu besar).
  2. Kerapuhan bidang data: konsumen crash alih-alih menurun dengan anggun.

Anda masih memperbaiki (2) dalam tinjauan kode. Tapi (1) adalah di mana blockchain bersinar: sebagai gerbang yang tahan-gangguan dan dapat diprogram di depan peluncuran.

"Konfigurasi pembawa-bukti" pada blockchain publik

Jika Anda memampatkan ide ini menjadi satu kalimat: tidak ada konfigurasi yang menjadi "saat ini" kecuali kontrak pintar mengatakannya, dan kontrak hanya membalik bendera itu setelah kunci waktu dan bukti bahwa artefak mematuhi invarian. Kalimat itu menyiratkan arsitektur lengkap.

Ternyata blockchain publik, terutama yang dibangun di atas Ethereum, rantai EVM yang menjalankan Ethereum Virtual Machine dan lapisan konsensus, menawarkan solusi yang baik untuk masalah tersebut.

Registry Konfigurasi on-chain sebagai gerbang promosi

  • Kontrak pintar pada EVM yang cepat dan kredibel (sering L2) mencatat setiap artefak kandidat, dan komitmen untuk bukti apa pun.
  • Penulisan dibatasi oleh kunci waktu dan multisig; sakelar jeda/matikan dan pointer rollback adalah kelas pertama.
  • Hanya hash atau bahkan skrip lengkap yang dapat masuk ke rantai. Jika offchain, blob berada di penyimpanan objek tetapi akan memberikan jaminan lebih sedikit. Ide bagus jika sepenuhnya onchain tidak mungkin karena ukuran, dan ketika data bersifat sementara adalah menggunakan blob EIP-4844. Meskipun penyimpanan terpisah, Anda dapat memasangkan hash onchain yang benar-benar dan blob dengan retensi 18 hari, yang bagus untuk jendela rollback bergulir.

Kesesuaian latensi. Ethereum menyelesaikan dalam epoch, tetapi L2 mengkonfirmasi dalam hitungan detik (OP Stack menargetkan ~2d; zkSync ~1d; banyak sistem mengekspos atestasi cepat). Ini cukup baik untuk irama bidang kontrol lima menit, lihat misalnya diskusi waktu blok OP atau waktu atestasi Circle).

Bukti wajib: membuat gerbang pintar

Lampirkan bukti ringkas dengan setiap artefak dan verifikasi di rantai. Itulah yang kami lakukan untuk protokol Chainwall kami, meskipun untuk jenis data yang berbeda!

Tujuan intinya adalah membuktikan properti dasar: row_count <= 200, diurutkan + unik berdasarkan kunci, skema cocok dengan regex dan aturan tipe, ukuran file <= N. Anda dapat memasukkan seluruh logika onchain, atau mengandalkan sirkuit Plonk/Groth untuk ekspresi yang lebih besar. Misalnya, tamu zk-VM dapat mengurai CSV/Parquet/JSON dan mengeluarkan SNARK. Anda tidak perlu mengungkapkan isinya, hanya komitmennya. Sistem penelitian dan produksi untuk regex dalam ZK ada (misalnya, Reef dan karya zk-regex terkait), yang membuat pemeriksaan skema realistis.

Ada dua jalur praktis:

  • Rute zkVM: Jalankan pemeriksa Anda di dalam zkVM dan verifikasi tanda terima di rantai; lihat kontrak verifikasi RISC Zero dan pembungkus bukti on-chain SP1 Succinct.
  • Rute sirkuit: Sirkuit tetap kecil untuk invarian di atas; untuk CSV/JSON + regex Anda dapat menggabungkan gadget penguraian dengan teknik zk-regex.

Distribusi yang tidak memperkenalkan kepercayaan baru

Edge melakukan polling registry dan hanya mengadopsi artefak yang disetujui di rantai. Untuk menghindari mempercayai RPC pihak ketiga, jalankan klien ringan di bidang kontrol Anda (misalnya, Helios) atau rencanakan untuk Portal Network. Dengan cara itu, edge memverifikasi header dan bukti inklusi secara lokal sebelum menerima keadaan "saat ini yang baru".

Sakelar matikan & rollback hanyalah bit dalam kontrak, yang dihormati oleh edge. Cloudflare secara eksplisit menyebutkan kebutuhan akan sakelar matikan global yang lebih kuat; menempatkan sakelar itu dalam kontrak kecil yang diaudit memberi Anda satu sumber kebenaran dalam tekanan.

Apakah ini benar-benar akan mengubah glitch CloudFlare?

  • File yang membengkak karena duplikasi melewati batas jumlah/ukuran yang ditegakkan oleh bukti, bukan oleh upaya terbaik. Promosi gagal.
  • Bahkan jika seseorang secara manual mengunggah blob ke penyimpanan, edge akan menolak untuk mengadopsinya tanpa bendera "saat ini" on-chain dan verifikasi bukti.
  • Anda masih memperbaiki kepanikan di proxy, tetapi Anda telah memindahkan tepi paling tajam dari risiko ke domain di mana sistem bukti dan kunci waktu sangat baik.

Mengapa kami bersikeras pada bidang kontrol on-chain murni untuk aset digital

Peristiwa CloudFlare bukan serangan, tetapi awalnya mereka mengira demikian dan itu memang mungkin! Seperti yang telah kita lihat dalam keamanan kripto: penyerang tidak hanya mengejar kunci; mereka memaksa bidang kontrol.

  • Perusakan front-end atau UI-penandatangan: Pencurian Bybit menunjukkan bagaimana memanipulasi apa yang dilihat penandatangan dapat mendorong persetujuan katastrofik. Analisis menunjuk pada phishing dan manipulasi UI alur persetujuan transaksi, bukan eksploitasi kontrak pintar. Baca catatan teknis NCC Group dan liputan dari Ledger Insights.
  • Otoritas API pihak ketiga: SwissBorg/Kiln bukan bug solidity; itu adalah jalur API off-chain yang memungkinkan penyerang mengacak otoritas staking dan menguras ~193k SOL seperti dijelaskan dalam pernyataan bersama Kiln.
  • Dari laptop pengembang ke kredensial cloud ke segalanya: Lazarus/TraderTraitor terus membuktikan bahwa mesin pengembang yang disusupi dan alur build yang ditipu memberi Anda pijakan cloud dan kekuatan untuk membengkokkan apa yang dilihat dan ditandatangani tim. Lihat misalnya penasihat CISA atau simulasi Elastic tentang bagaimana kredensial AWS bocor dari kotak dev.

Kesimpulan

Posisi kami: kontrol aset digital harus berada dalam kontrak pintar yang dijaga oleh kunci waktu dan multisig, bukan dalam kredensial pribadi, token CI, ACL cloud, atau dasbor admin. Jika tindakan deploy atau "ubah pemilik" Anda harus melewati jalur schedule() dan execute() kontrak, bahkan rootkit di laptop pengembang tidak dapat melompati antrian. Penundaan waktu adalah pemutus sirkuit yang dapat Anda andalkan, dan jejak audit on-chain bersifat objektif. Itu hanya menyisakan pertanyaan "bagaimana jika hal yang kita promosikan cacat?" yang persis dijawab oleh "konfigurasi pembawa-bukti".

Kami juga percaya ada pasar yang cukup besar untuk aplikasi dengan kepercayaan minimal. Kami hanya membangun fondasi yang tepat sekarang untuk kasus penggunaan pertama yang terdefinisi dengan baik di OKcontract Labs.


When a Feature File Tripped the Internet awalnya dipublikasikan di Coinmonks di Medium, di mana orang-orang melanjutkan percakapan dengan menyoroti dan menanggapi cerita ini.

Penafian: Artikel yang diterbitkan ulang di situs web ini bersumber dari platform publik dan disediakan hanya sebagai informasi. Artikel tersebut belum tentu mencerminkan pandangan MEXC. Seluruh hak cipta tetap dimiliki oleh penulis aslinya. Jika Anda meyakini bahwa ada konten yang melanggar hak pihak ketiga, silakan hubungi [email protected] agar konten tersebut dihapus. MEXC tidak menjamin keakuratan, kelengkapan, atau keaktualan konten dan tidak bertanggung jawab atas tindakan apa pun yang dilakukan berdasarkan informasi yang diberikan. Konten tersebut bukan merupakan saran keuangan, hukum, atau profesional lainnya, juga tidak boleh dianggap sebagai rekomendasi atau dukungan oleh MEXC.