727 FinanceSebuah insiden tidak hanya merenggut aset, tetapi juga kepercayaan. Kripto tidak bisa terus seperti ini; kita harus menyelamatkan diri kita sendiri.
Penulis: Robert Mao, Pendiri dan CEO ArcBlock
Artikel ini diizinkan untuk direproduksi dan diteruskan secara bebas oleh siapa saja, dengan harapan lebih banyak orang akan melihat seruan agar industri ini menyelamatkan dirinya sendiri.
Crypto tidak bisa terus seperti ini. Lagi dan lagi, pencurian besar-besaran tidak hanya merampas aset, tetapi juga kepercayaan peserta terhadap seluruh industri. Kita harus menyelamatkan diri kita sendiri.
Pada 29 Oktober 2026, terjadi insiden keamanan besar di Binance. Pengumuman awalnya memperkirakan sekitar $6,3 miliar aset terdampak, dan sekitar $3 miliar dari aset yang terdampak telah dibekukan; investigasi awalnya mengarah pada laptop seorang insinyur DevOps, dan kemudian titik intrusi lain yang mungkin juga ditemukan. Binance juga menyatakan bahwa tidak ditemukan bukti kebocoran private key dompet. Jumlah yang terdampak bukanlah kerugian bersih final, dan rantai serangan lengkap masih dalam penyelidikan. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Inisiatif ini ditujukan kepada para pembangun proyek blockchain seperti Ethereum dan Solana, dan juga kepada Binance, Coinbase, Kraken, serta semua bursa, dompet, protokol, dan pembangun keamanan yang bersedia berpartisipasi: mari kita bangun kembali fondasi untuk melindungi aset bersama-sama. Saya bersedia berpartisipasi, dan saya berharap lebih banyak orang akan bertindak bersama.
Ini sudah cukup berat. Namun yang lebih mengkhawatirkan saya adalah seberapa besar kepercayaan terhadap Crypto yang akan dihancurkan oleh insiden ini, dan berapa banyak penyerang yang akan menganggap industri ini sebagai target yang masih layak untuk terus diserang. Bahkan jika seseorang pada akhirnya menanggung kerugiannya, kompensasi tidak dapat secara otomatis memulihkan kepercayaan pengguna, juga tidak dapat menghentikan jenis kehancuran yang sama terjadi lagi.
Binance hanyalah titik masuk yang memaksa kita menghadapi masalah ini hari ini. Jika kita berpaling, bursa, bridge, protokol on-chain, dan dompet telah lama meninggalkan jejak luka yang panjang. Jaringan dan produk baru terus muncul, namun mode kegagalan lama berulang lagi dan lagi. Kita tidak bisa menerbitkan pengumuman, menunggu beberapa saat, lalu menganggap insiden berikutnya sebagai hal rutin.
Kita juga harus mengakui bahwa penipuan dan praktik sekadar menciptakan konsep tanpa bertanggung jawab untuk membangun telah merugikan industri ini terlalu lama. Tim yang serius membangun teknologi dan infrastruktur juga harus menanggung konsekuensi dari hilangnya kepercayaan bersama-sama. Pada saat orang melihat seluruh Crypto sebagai penipuan, teknologi dan eksplorasi yang benar-benar layak dipertahankan mungkin juga akan ditinggalkan bersamanya.
Sebagai pendiri ArcBlock dan seorang praktisi di Crypto dan Blockchain, saya tidak mau menerima hasil seperti itu. Saya percaya industri ini memiliki nilai yang layak dilindungi, dan saya juga percaya kita harus bertanggung jawab atas fondasi keamanan kita sendiri. Jika kita terus pasif menunggu insiden berikutnya, pendarahan yang berulang pada akhirnya mungkin akan menghancurkan semua yang telah kita bangun bersama.Jadi, saya ingin mengajukan inisiatif ini: para pembangun bursa, dompet, dan blockchain harus bersama-sama membangun kembali fondasi kontrol aset dan verifikasi keamanan, sehingga cakupan kerusakan dari satu intrusi dapat dibatasi. Linimasa di bawah ini menjelaskan mengapa perubahan diperlukan; proposal teknis yang menyusul adalah pekerjaan yang saya yakini dapat kita mulai lakukan.
Pada tahun 2008, Satoshi Nakamoto mengusulkan sistem kas elektronik peer-to-peer, yang berupaya membuat pembayaran kurang bergantung pada perantara tepercaya. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Namun insiden-insiden besar sejak saat itu berulang kali mengekspos masalah dana, otorisasi, dan dependensi perangkat lunak yang kembali terkonsentrasi.
Berikut adalah daftar kronologis insiden representatif di area seperti bursa terpusat (CEX), bursa terdesentralisasi (DEX), bridge, dan dompet. Ini bukan basis data insiden yang lengkap, juga bukan statistik kerugian tahun demi tahun. Jika jumlah dicantumkan, jumlah tersebut merujuk pada perkiraan dampak bruto pada saat insiden; pencurian, pembekuan, dan pemulihan selanjutnya dijelaskan secara terpisah dan tidak dapat dijumlahkan sebagai kerugian permanen.
2008 · Whitepaper Bitcoin
Titik awal
Whitepaper Bitcoin mengusulkan pembayaran peer-to-peer tanpa lembaga keuangan sebagai perantara.
Sumber
2011–2014 · Pencurian jangka panjang Mt. Gox
CEX
Mt. Gox mengalami pencurian jangka panjang dan akhirnya menghentikan operasi. Dakwaan Departemen Kehakiman AS kemudian menuduh bahwa sekitar 647.000 BTC dicuri antara tahun 2011 dan 2014. Ini bukan serangan satu hari pada tahun 2014.
Sumber
2012 · Bitcoinica dan Bitfloor
CEX / infrastruktur kustodian
Lingkungan hosting Linode Bitcoinica disusupi; pada tahun yang sama, cadangan dompet Bitfloor yang tidak terenkripsi menjadi titik masuk serangan. Server dan cadangan di balik platform juga merupakan bagian dari batas keamanan aset.
Sumber
2015 · Hot wallet Bitstamp
CEX
Hot wallet Bitstamp disusupi, dan lingkungan operasi kemudian dibangun kembali. Pembedaan resmi antara cakupan insiden dan cadangan offline menunjukkan bahwa isolasi dapat membatasi cakupan eksposur.
Sumber
2016 · Bitfinex
CEX
Sekitar 120.000 BTC dicuri dari Bitfinex. Pengaturan multisignature tetap memerlukan otorisasi dan verifikasi independen end-to-end.
Sumber 1 · Sumber 2
2016 · The DAO
Protokol on-chain
Kontrak The DAO mengalami serangan reentrancy, dan sekitar 3,6 juta ETH dipindahkan ke sub-DAO, yang kemudian memicu fork Ethereum. Jalur eksekusi yang sah dapat menghasilkan hasil bisnis yang katastrofik.
Sumber 1 · Sumber 2
2017 · Pustaka dompet bersama Parity
Dompet kontrak
Pustaka dompet bersama Parity dihancurkan, dan sekitar 513.000 ETH dibekukan. Bahkan jika tidak dipindahkan, dana dapat menjadi tidak dapat digunakan karena dependensi kode bersama.
Sumber
2018 · Coincheck
CEXHot wallet NEM Coincheck dicuri. Batas antara cadangan offline, izin hot wallet, dan kebutuhan bisnis sekali lagi menjadi masalah.
Sumber
2019 · Binance
CEX
Binance mengumumkan bahwa 7.000 BTC ditarik dalam satu transaksi. Arus keluar aset berskala besar perlu dibatasi sebelum penandatanganan.
Sumber
2020 · KuCoin
CEX
Insiden hot wallet KuCoin, dengan sejumlah besar aset kemudian dipulihkan melalui kolaborasi multipihak. Jumlah bruto yang dicuri dan kerugian akhir bukanlah angka yang sama.
Sumber
2021 · Poly Network
Protokol lintas rantai
Sekitar $612 juta aset dipindahkan keluar dari Poly Network dan kemudian dikembalikan secara bertahap. Otorisasi lintas rantai dan kontrol aset tidak dapat bertahan hanya melalui jalur bisnis normal.
Sumber
2022 · Jembatan Ronin
Jembatan
Izin validator Ronin dikompromikan, dan 173.600 ETH serta 25,5 juta USDC dipindahkan keluar. Kunci dari beberapa validator juga dapat jatuh ke dalam rantai serangan yang sama.
Sumber
2022 · Dompet Slope
Dompet
Insiden dompet Slope di ekosistem Solana. Solana secara resmi menyatakan bahwa informasi kunci privat secara tidak sengaja terkirim ke layanan pemantauan aplikasi; itu bukan kompromi konsensus Solana.
Sumber
2023 · Euler
Protokol pinjaman
Sekitar $197 juta aset dipindahkan keluar dari Euler akibat kerentanan protokol dan kemudian dipulihkan. Kombinasi kompleks dalam satu transaksi dapat memperbesar cacat logika bisnis.
Sumber
2023 · Ledger Connect Kit
Alat koneksi dompet
Ledger Connect Kit mengalami serangan rantai pasokan, dan kode berbahaya masuk ke frontend aplikasi. Keamanan perangkat keras tidak dapat menggantikan verifikasi konten transaksi.
Sumber
2024 · DMM Bitcoin
CEX
Sekitar $308 juta dicuri dari DMM Bitcoin. FBI dan lembaga lain kemudian mengungkap serangan rekayasa sosial yang menargetkan personel terkait dan rantai penandatanganan.
Sumber
2024 · Radiant Capital
Protokol pinjaman / penandatanganan
Sekitar $50 juta dicuri dari Radiant Capital, dan beberapa perangkat pengembang dikompromikan. Penandatanganan multipihak masih dapat secara kolektif bergantung pada informasi transaksi yang terkontaminasi.
Sumber
2025 · Bybit / Safe
CEX / frontend dompet
Insiden Bybit senilai sekitar $1,5 miliar melibatkan lingkungan pengembang dan frontend Safe, dan penandatangan menyetujui transaksi yang mengubah logika kontrol dompet.
Sumber 1 · Sumber 2
2025 · Cetus DEX
DEXInsiden senilai sekitar $223 juta di Cetus pada Sui, dengan para peneliti menunjuk ke cacat pada pustaka matematika. Lingkungan non-EVM juga harus memeriksa kode dan cakupan eksposur aset mereka.
Sumber
2026-07 · Cacat angka acak COLDCARD
Dompet perangkat keras / pembuatan seedCacat firmware melemahkan pembangkitan seed, memungkinkan penyerang merekonstruksi private key terkait saat perangkat offline. Peningkatan versi tidak dapat memperbaiki seed lemah yang sudah terbentuk; migrasi sesuai advisory tetap diperlukan.
Sumber
2026-10 · Implan perangkat keras Ledger
Dompet perangkat keras / serangan distribusi
Ledger mengonfirmasi bahwa perangkat asli dimodifikasi dan diedarkan melalui saluran distribusi di Asia Tenggara, dengan komponen yang ditanamkan mencuri recovery phrase selama inisialisasi. Vendor menyatakan chip, sistem operasi, dan servernya tidak dikompromikan.
Sumber
2026 · Insiden multi-chain Binance
CEX / multi-chain
Binance awalnya memperkirakan sekitar $6,3 miliar aset terdampak, dan investigasi terhadap titik intrusi lain yang mungkin masih berlangsung. Satu sistem operasi dapat mengekspos aset di berbagai jaringan secara bersamaan.
Sumber 1 · Sumber 2 · Sumber 3
Di sini ada CEX, tetapi juga decentralized exchange, protokol lending, dan bridge; ada aset yang dicuri, dan aset yang dibekukan. Serangan terjadi pada lapisan yang berbeda, dan metode remediasinya berbeda. Saya menolak mereduksi semua ini menjadi satu kalimat "pengguna gagal menjaga private key mereka." Bagaimana pengguna bisa tahu bahwa lingkungan pengembangan suatu alat, suatu shared library, atau otorisasi yang tidak dapat dipahami akan menjadi titik masuk ke seluruh aset mereka?
Jaringan terdistribusi telah melakukan banyak hal, namun fault isolation untuk kontrol aset masih jauh dari memadai. Eksekusi on-chain dengan setia menyelesaikan suatu transaksi, tetapi tidak dapat menjawab bagi kita mengapa transaksi tersebut berhak memindahkan begitu banyak.
Kontribusi Ethereum signifikan. Ethereum memungkinkan lebih banyak orang menulis aplikasi on-chain dan menumbuhkan seperangkat alat serta pengalaman pengembangan yang kaya. Namun hari ini, banyak chain baru dan L2 (jaringan penskalaan layer-2) menjadikan kompatibilitas EVM sebagai tujuan utama mereka. EVM, mesin virtual yang mengeksekusi smart contract Ethereum, menjadi premis teknis yang direplikasi secara luas. Kompatibilitas memang memudahkan migrasi aplikasi; dokumentasi proyek seperti Unichain secara eksplisit menyebut penggunaan ulang tooling Ethereum sebagai nilai dari lingkungan eksekusi yang setara. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Saya berpendapat bahwa menjadikan kompatibilitas EVM sebagai jawaban default industri menciptakan konsentrasi risiko struktural. Nama jaringan bisa banyak, validator bisa berbeda, tetapi pengembang dapat berulang kali men-deploy kontrak yang sama, menggunakan kebiasaan otorisasi yang sama, dan bergantung pada library perangkat lunak yang sama. Kesalahan pada dependensi bersama tidak hilang hanya karena deployment dilakukan di chain lain. Ini adalah penilaian tentang jalur teknis, bukan klaim bahwa setiap implementasi EVM pasti memiliki kerentanan yang sama.Di sinilah juga letak kritik saya terhadap Ethereum. Kemampuan eksekusi kontrak serbaguna terhubung langsung dengan aset yang dapat ditransfer, sehingga menempatkan tanggung jawab yang sangat besar pada kode aplikasi dan interaksi dompet. Kontrak dapat memanggil kontrak, otorisasi dapat bertahan untuk waktu yang lama, dan konfirmasi yang tampak biasa dapat mengubah mode kontrol akun selanjutnya. Keamanan semakin bergantung pada setiap tim pengembang untuk memahami kombinasi ini dengan benar, dan pada setiap pengguna untuk memahami dengan benar apa yang telah mereka tandatangani.
EIP-7702 membuat masalah ini sangat jelas. Transfer biasa adalah "berapa banyak kepada siapa kali ini"; otorisasi delegasi mungkin berarti "mulai sekarang, biarkan potongan kode ini menjalankan operasi atas nama akun saya." Tujuannya adalah meningkatkan pengalaman pengguna dan menyempurnakan izin, tetapi menyiapkan delegasi itu sendiri memberikan kemampuan eksekusi yang luas, dan izin yang terperinci tetap harus diimplementasikan dengan benar oleh kode yang didelegasikan. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Preprint "EIP-7702 Phishing Attack" oleh Minfeng Qi dkk. mempelajari jalur pengendalian akun secara persisten setelah menginduksi penandatanganan otorisasi semacam itu. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) Seiring meningkatnya kenyamanan, tanggung jawab keamanan juga meningkat; yang pertama tidak bisa begitu saja diserahkan kepada pengguna.
Insiden Binance ini mencakup beberapa rantai, dan penyelidikannya belum selesai, sehingga seluruh dampaknya tidak dapat langsung diatribusikan kepada EIP-7702 atau EVM. Reentrancy, kompromi layanan penandatanganan, dan manipulasi front-end juga bukan kerentanan yang sama. Namun pembedaan semacam itu tidak boleh menjadi alasan untuk berhenti mempertanyakan arsitektur: mengapa lapisan dasar tidak mempertahankan lebih banyak batasan yang tidak dapat dengan mudah dilewati, atas nama kesalahan di lapisan atas?
MEV juga membuat saya tidak puas. Ini merujuk pada ruang di mana peserta memperoleh nilai tambah melalui penyertaan, pengecualian, dan pengurutan transaksi. Bagi saya, menggunakan kekuatan pengurutan untuk melakukan sandwich terhadap transaksi pengguna dan memperburuk hasil eksekusi mereka harus diperlakukan sebagai bug yang perlu diperbaiki, bukan dikemas sebagai fitur yang layak dipertahankan hanya karena seseorang dapat memperoleh keuntungan darinya. Dokumentasi Ethereum sendiri juga secara eksplisit mengakui bahaya sandwich transaksi bagi pengguna dan risiko MEV terhadap stabilitas jaringan. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV bukanlah hal yang unik bagi Ethereum dan juga mencakup berbagai aktivitas berbeda seperti arbitrase dan likuidasi; industri sudah memiliki penelitian mitigasi. Kritik saya adalah bahwa insentif untuk mempertahankan jaringan tidak boleh menjadi alasan untuk mengorbankan kondisi transaksi pengguna. Sistem transaksi yang lebih baik harus menuliskan hasil pengiriman minimum dan biaya yang diizinkan ke dalam otorisasi, serta membatasi ruang bagi pengurut untuk menggunakan informasi yang belum terisi untuk merugikan pengguna.Saya selalu merasa bahwa dampak Ethereum terhadap Crypto agak mirip dengan dampak PHP terhadap Internet: keduanya memungkinkan banyak orang membangun sesuatu, dan juga meninggalkan utang teknik yang akan membutuhkan waktu lama untuk dilunasi. PHP masih perlu memperbaiki kerentanan eksekusi kode jarak jauh yang parah pada Oktober 2026. Kematangan dan popularitas tidak dapat menggantikan penguatan berkelanjutan. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Yang berharga dari Internet adalah bahwa bahasa, framework, dan layanan cloud dapat berevolusi secara terpisah. Kita juga harus membiarkan model aset dan metode eksekusi yang berbeda terus berkembang, alih-alih memperlakukan "kompatibilitas dengan mesin virtual yang sama" sebagai tiket untuk berpartisipasi dalam ekosistem.
Oleh karena itu, saya menyerukan ekosistem Bitcoin, Solana, dan Ripple/XRP Ledger, serta para pembangun termasuk ArcBlock, untuk serius berpartisipasi dalam membangun fondasi keamanan bersama. Berpartisipasi dalam standar dan interoperabilitas tidak memerlukan diri sendiri terlebih dahulu diubah menjadi Ethereum. Keberagaman harus diimplementasikan dalam kontrol aset dan metode verifikasi serta terbuka terhadap pengawasan publik. Insiden Slope dan Cetus telah mengingatkan kita bahwa non-EVM juga tidak memiliki pengecualian keamanan.
Yang saya harapkan terwujud adalah spesifikasi keamanan yang dapat diadopsi oleh lingkungan eksekusi yang berbeda: batas aset dan persyaratan verifikasi yang sama dapat diimplementasikan secara terpisah oleh EVM dan jalur lainnya, lalu jaminan dan biaya masing-masing dapat diperiksa secara publik.
1. Biarkan kontrol risiko yang mendasari membatasi kekuasaan untuk membuang aset
Dompet besar harus dapat menetapkan daftar putih penerima, batas pengeluaran kumulatif, dan periode tunggu untuk penerima baru. Kuncinya adalah aturan-aturan ini tidak dapat segera dibatalkan oleh kunci transaksi harian yang sama. Mengubah aturan memerlukan otorisasi independen dan harus menyisakan waktu untuk pemantauan dan pencabutan.Akun pintar yang sudah ada telah memiliki dasar implementasi, misalnya Safe Guards dapat menambahkan pembatasan transaksi di luar multisig. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Kita perlu menjadikan ini sebagai kemampuan fondasional yang lebih mudah diadopsi yang mencakup semua jalur pengendalian aset. Jika hanya transfer langsung yang dibatasi sementara bypass melalui persetujuan tak terbatas, modul, atau upgrade diizinkan, perlindungan akan gagal. Apakah kontrak whitelist dapat di-upgrade dan apakah izin penerima telah berubah juga harus masuk ke dalam cakupan verifikasi. Activation Lock dari Apple menawarkan inspirasi dalam kehidupan sehari-hari: fitur ini membatasi aktivasi ulang perangkat yang dicuri dan membatasi kalibrasi komponen tertentu yang dicuri, dengan tujuan mengurangi nilai yang dapat dieksploitasi setelah pencurian. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Dompet juga layak dirancang ke arah ini. Jika penyerang memperoleh kunci, rentang aset yang dapat dicairkan tetap terbatas, dan ekspektasi imbal hasil dari serangan mungkin menurun; risiko seperti gangguan layanan masih perlu ditangani secara terpisah.
Inilah yang saya sebut "konstitusi" keamanan aset: otoritas operasional mungkin dapat dikompromikan, tetapi otoritas untuk mengubah batas harus tetap independen. Proses pemulihan juga harus dibatasi, untuk mencegah satu kesalahan konfigurasi mengunci aset secara permanen.
II. Jadikan dompet memikul tanggung jawab keamanan, bukan sekadar menyerahkan kata mnemonic
Saya memiliki ketidakpuasan yang kuat terhadap sistem dompet saat ini: jika sebuah produk meminta orang biasa menyalin serangkaian kata, menuntut agar mereka tidak pernah membocorkan, kehilangan, atau tertipu untuk memberikannya, lalu mengatribusikan semua kegagalan berikutnya kepada tanggung jawab pengguna, saya menganggap ini sebagai desain yang tidak bertanggung jawab. Kustodi mandiri seharusnya memberi orang kendali, dan juga harus memberi orang kemampuan perlindungan dan pemulihan yang dapat digunakan. Ini tidak seharusnya menuntut setiap pengguna untuk terlebih dahulu menjadi ahli keamanan. Ini juga merupakan ambang batas yang harus dilalui Crypto untuk menjangkau lebih banyak pengguna biasa.Insiden terkini telah menempatkan masalah ini tepat di atas meja. Pada Oktober 2026, Ledger mengonfirmasi bahwa penyerang memodifikasi perangkat asli dan kemudian mengirimkannya kembali ke pasar melalui saluran distribusi di Asia Tenggara, dengan komponen yang ditanamkan mencuri recovery words selama inisialisasi. Ledger mendefinisikan ini sebagai serangan distribusi terlokalisasi setelah perangkat meninggalkan pabrik, bukan kompromi pada chip, sistem operasi, atau servernya. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) Insiden COLDCARD pada Juli melibatkan pelemahan firmware pada pembangkitan seed: perangkat tidak perlu dikendalikan dari jarak jauh bagi penyerang untuk merekonstruksi private key yang relevan. Memperbarui firmware memperbaiki proses pembangkitan ke depannya, tetapi seed lemah yang sudah dibangkitkan tetap perlu dimigrasikan. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Kedua insiden ini bukan jenis kerentanan yang sama, namun bersama-sama menunjukkan: bahkan jika pengguna dengan cermat menyalin kata-kata dan menjaga perangkat tetap offline, mereka tidak dapat memverifikasi keacakan dan integritas rantai pasok atas nama produsen. Menampilkan backup words pada perangkat memiliki tujuan pemulihan offline, tetapi juga menyebabkan rahasia pemulihan lengkap melewati jalur tampilan dan pencadangan yang perlu dilindungi. Keamanan chip tidak dapat menggantikan verifikasi seluruh perangkat dan proses pengiriman.
Tujuan perbaikan haruslah siklus hidup dompet secara menyeluruh: bagaimana key dibangkitkan, bagaimana transaksi dijelaskan, bagaimana izin dipisahkan, dan bagaimana pemulihan bekerja setelah perangkat hilang. Abstraksi akun, yaitu memungkinkan akun memverifikasi otorisasi melalui aturan yang dapat diprogram, dan backup threshold seperti SLIP-39, keduanya sudah memiliki standar dan dasar implementasi, sehingga tidak dapat dikatakan tidak ada pihak di industri yang mengerjakannya. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Namun kita perlu menjadikan kemampuan ini sebagai perlindungan yang teruji dan mudah digunakan, bukan membiarkan pengguna merakit skema kompleks sendiri.
Obfuskasi sederhana pada mnemonic words tidaklah cukup. Arah yang lebih andal mencakup backup terenkripsi yang telah ditinjau, pemulihan threshold, dan otorisasi perangkat independen, serta membuat pengguna menyelesaikan latihan pemulihan sebelum menyetorkan aset dalam jumlah besar. Backup shard dan multisig adalah lapisan yang berbeda: yang pertama mungkin bergabung kembali menjadi rahasia yang sama selama pemulihan, sedangkan yang kedua memerlukan beberapa penandatangan independen untuk menyetujui transaksi. Layanan pemulihan tidak boleh diam-diam menjadi master key baru, dan kata sandi tambahan juga tidak boleh menjadi jebakan lain di mana kehilangannya berarti kerugian yang tidak dapat dipulihkan.Dompet pribadi dan sistem dompet bursa dapat berbagi spesifikasi keamanan untuk deskripsi transaksi, permintaan penandatanganan, pembatasan aset, dan proses pemulihan, sambil mengadopsi batas dan kebijakan persetujuan yang berbeda. PSBT Bitcoin sudah menyediakan format untuk meneruskan transaksi yang belum ditandatangani antar alat, dan antarmuka umum ini layak untuk terus dikembangkan. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Yang umum adalah persyaratan keamanan yang dapat diperiksa; setiap rantai tetap perlu memperjelas aturan adaptasinya sendiri. Dompet harus secara jelas menyajikan apa yang akan dipindahkan oleh tanda tangan ini dan berapa banyak kewenangan lanjutan yang diberikannya kepada siapa, dan kebijakan independen harus menolak operasi di luar batas; halaman konfirmasi yang lebih cantik saja tidak cukup.
III. Mencapai keterverifikasian dengan pengungkapan minimal yang diperlukan
Membuktikan bahwa suatu kondisi terpenuhi tidak selalu mengharuskan pengguna mengungkapkan semua data yang mendasarinya. Pengungkapan selektif, bukti tanpa pengetahuan, dan akses audit yang diberikan berdasarkan permintaan harus menjadi opsi normal dalam infrastruktur. Ini juga terkait dengan keamanan aset: identitas publik dan hubungan aset dapat memberikan petunjuk untuk penipuan yang ditargetkan; data yang tidak dibutuhkan bisnis harus diungkapkan sesedikit mungkin.
Sistem kredensial yang dapat diverifikasi W3C sudah memiliki jalur teknis untuk pengungkapan selektif; namun, membuktikan bahwa input autentik, bahwa kredensial tetap valid, dan bagaimana statusnya dicabut masih perlu diperjelas. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Mengadopsi bukti tanpa pengetahuan (ZK) tidak secara otomatis menyembunyikan jumlah dan hubungan transaksi; penskalaan bukti dan perlindungan privasi adalah tujuan yang berbeda.
Misalnya, ketika bisnis hanya perlu memverifikasi kelayakan untuk berpartisipasi, pengguna dapat menyajikan kesimpulan kelayakan yang valid yang diterbitkan oleh lembaga tepercaya tanpa mengungkapkan materi keuangan lengkap. Ketika perlu membuktikan bahwa nilai tersembunyi memenuhi suatu kondisi, mekanisme bukti yang sesuai kemudian dapat digunakan. Sumber tepercaya dari kredensial dan status pencabutannya tetap perlu diverifikasi.
Inisiatif saya adalah pertama-tama memperjelas "siapa yang perlu memverifikasi apa," lalu merancang data yang harus diungkapkan kepada publik. Mereka yang memverifikasi kelayakan mungkin hanya memerlukan kesimpulan kelayakan; mereka yang memikul tanggung jawab audit tertentu dapat memperoleh bukti terbatas. Batasan yang dapat diverifikasi secara publik harus meminimalkan informasi pribadi yang terekspos secara permanen kepada semua orang.
IV. Membuat layanan transaksi sebebas mungkin dari kustodi terpusatPencocokan perdagangan, pencarian jalur, dan penyelesaian aset harus dirancang secara terpisah. Layanan yang menyediakan titik masuk perdagangan harus memperoleh hanya izin yang diperlukan untuk menyelesaikan penyelesaian saat ini sejauh mungkin, sehingga aset pengguna tetap berada di bawah kendali masing-masing sepanjang waktu lainnya. Protokol transaksi berbasis niat yang ada telah menjajaki sebagian jalur, dan industri dapat terus melengkapinya. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
Apa yang disetujui pengguna harus berupa kondisi penyelesaian yang jelas, termasuk apa yang dibayarkan, apa yang diterima secara minimum, kapan kedaluwarsa, dan biaya yang diizinkan. Setelah layanan perdagangan disusupi, penyerang dapat menolak layanan, tetapi tidak dapat secara sewenang-wenang mengubah kondisi ini. Bisnis yang masih memerlukan kustodian terpusat juga harus memisahkan izin cadangan dan operasional, serta membatasi eksposur hot wallet dan batas pengisian ulang otomatis.
IBIT adalah produk perdagangan bitcoin iShares, dan yang diperdagangkan di pasar adalah sahamnya. Pengaturannya memberikan contoh isolasi parsial: saham dan Bitcoin yang mendasarinya dicatat secara terpisah, dan kunci privat yang relevan untuk Vault Balance (saldo kustodian) ditempatkan di penyimpanan dingin. Perubahan dalam catatan perdagangan saham tidak memerlukan Bitcoin yang mendasarinya untuk bergerak pada setiap transaksi. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Yang dapat dipelajari dari ini adalah pemisahan hak perdagangan dan hak pembuangan cadangan. Trading Balance (saldo layanan perdagangan) memiliki pengaturan yang berbeda, dan kustodian itu sendiri juga membawa risiko; penyimpanan dingin harus dipasangkan dengan instruksi independen dan verifikasi tanda tangan.
Saya membandingkan titik masuk perdagangan dengan router dengan harapan dapat diganti tanpa membawa sakelar utama atas semua aset pengguna. Penyelesaian lebih kompleks daripada penerusan paket, dan pengiriman aset serta otorisasi masih perlu diverifikasi secara independen. Menjadikan layanan non-kustodian lalu memberinya hak penarikan tanpa batas hanya akan membawa kembali risiko terpusat.
V. Gunakan arsitektur berlapis untuk mengisolasi kegagalan dan mempertahankan kemampuan penggantianKita memerlukan antarmuka identitas dan otorisasi, kebijakan aset, serta metode verifikasi penyelesaian yang dapat berkembang secara independen. Rantai yang berbeda dapat mempertahankan model eksekusinya sendiri dan terhubung melalui antarmuka yang jelas. Antarmuka harus menyatakan jaminan keamanan dan kondisinya, bukan sekadar mengatakan "panggilan berhasil."Pengalaman internet mendukung pendekatan ini. Dalam RFC 9518, "Centralization, Decentralization, and Internet Standards," Mark Nottingham secara khusus membahas situasi di mana sentralisasi dapat membantu, dan juga menganalisis kekuatan dan risiko yang dibawanya. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Ini justru sikap yang layak dipelajari: biarkan arsitektur menjawab tanggung jawab mana yang dapat disentralisasi, sampai tingkat apa, dan bagaimana mencegah kekuatan itu meluas. Sebuah layanan dapat diizinkan untuk mengidentifikasi anomali secara terpusat sementara izinnya untuk menyentuh aset dibatasi; pengguna harus dapat beralih layanan tanpa kehilangan kebijakan aset dan catatan verifikasi mereka sendiri.
Pertanyaan penerimaan yang paling penting adalah: setelah layanan bisnis dikompromikan, lapisan independen mana yang masih dapat menolaknya? Jika semua lapisan berbagi satu kunci administratif, apa yang disebut pelapisan hanyalah pelapisan pada diagram deployment.
Tujuan ini dapat dilihat sebagai lima lapisan tanggung jawab: layanan transaksi mengirimkan permintaan, dompet menyatakan niat pengguna, kebijakan independen membatasi otoritas atas disposisi aset, komponen verifikasi memeriksa operasi dan bukti, dan lapisan penyelesaian menegakkan batasan dan menyediakan catatan yang dapat diverifikasi. Semuanya dapat diimplementasikan oleh tim yang berbeda, dan dependensi serta kondisi kegagalannya juga harus dijelaskan secara terpisah.
Arsitektur target yang dianjurkan dalam artikel ini. Lapisan penyelesaian harus menegakkan kebijakan aset; prompt di dompet tidak dapat menggantikan batasan ini. Penandatanganan harian, perubahan aturan, dan otoritas pemulihan perlu diisolasi dan diuji terhadap bypass.
6. Biarkan pengguna memverifikasi aset mereka sendiri dengan ringan
Orang biasa tidak harus menyimpan dan mengeksekusi seluruh riwayat seluruh rantai untuk memverifikasi saldo dan tanda terima mereka sendiri; mereka juga tidak harus hanya mempercayai satu server di belakang dompet. Satoshi Nakamoto sudah mengusulkan SPV, verifikasi pembayaran yang disederhanakan, dalam Bagian 8 whitepaper. BIP-157 Bitcoin terus mengeksplorasi memungkinkan klien mengunduh filter dan menemukan blok yang terkait dengan diri mereka sendiri; Ethereum juga memiliki desain klien ringan. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Jadi masalahnya bukanlah tidak ada yang pernah memikirkannya, tetapi kita masih perlu membangun kemampuan verifikasi dengan kondisi keamanan yang jelas ke dalam dompet yang digunakan pengguna setiap hari.Ambil contoh rantai yang mendukung bukti status akun: saat menanyakan saldo, server harus mengembalikan saldo sekaligus bukti. Dompet terlebih dahulu memverifikasi digest blok pendek, yaitu header blok, sesuai aturan rantai tersebut, lalu memeriksa apakah saldo ini konsisten dengan data yang dikomit oleh digest tersebut. Server memberikan jawaban, dan dompet dapat memverifikasi jawaban itu. SPV Bitcoin memverifikasi bukti bahwa transaksi relevan telah disertakan; itu tidak dapat langsung disalin sebagai bukti saldo. Dompet juga harus menampilkan dengan jelas sampai mana ia telah tersinkronisasi dan informasi mana yang telah diverifikasi; ketika bukti hilang, data kedaluwarsa, atau sumber bertentangan, dompet harus memperingatkan atau menghentikan operasi berisiko tinggi yang bergantung pada informasi ini, dan tidak boleh diam-diam kembali ke kepercayaan buta.
Verifikasi ringan tetap memiliki syarat. Membuktikan bahwa sebuah transaksi telah disertakan dalam blok tidak sama dengan memeriksa sendiri bahwa semua transaksi dalam blok itu valid. Skema yang berbeda mungkin bergantung pada mayoritas hash power yang jujur, atau pada catatan awal yang tepercaya, yaitu checkpoint; mereka juga harus waspada terhadap server yang menahan data atau mengisolasi pengguna pada catatan rantai yang kedaluwarsa. Apakah kueri itu sendiri mengekspos alamat yang menjadi perhatian pengguna juga perlu ditangani. Node penuh dan produsen blok bukanlah peran yang sama; Ethereum saat ini menggunakan validator alih-alih penambang untuk produksi blok.
Lebih penting lagi, membuktikan bahwa "transfer ini benar-benar terjadi on-chain" tidak dapat membuktikan bahwa "ini tepatnya transfer yang diinginkan pengguna." Klien ringan tidak dapat menggantikan batas aset dan pemeriksaan tanda tangan sebelumnya. Mereka membuat pengguna lebih sedikit bergantung pada jawaban yang tidak dapat diverifikasi, sementara kebijakan aset memastikan bahwa bahkan tanda tangan yang valid tidak dapat membuang aset tanpa batas. Hanya dengan membangun kedua lapisan bersama-sama, kemampuan verifikasi dapat didistribusikan di antara para peserta.
7. Bangun identifikasi anomali dan verifikasi keamanan sebagai infrastruktur publik
Sebelum transaksi, seseorang harus memeriksa apakah operasi mematuhi kebijakan aset dan apakah tiba-tiba mengubah perilaku historis. Anomali yang jelas dapat memicu jeda atau tinjauan yang ditingkatkan; perluasan izin memerlukan jalur independen lain. AI dapat berpartisipasi dalam penilaian, tetapi tidak boleh menerima izin yang mengesampingkan aturan keras.
Pada saat yang sama, kita perlu bersama-sama memelihara kasus serangan, pengujian izin, dan alat verifikasi yang dapat dijalankan berulang kali. Hanya dengan berbagi spesifikasi dan mempertahankan implementasi independen serta verifikasi independen, kegagalan common-mode dapat dikurangi. Yayasan dan bursa sudah memiliki investasi keamanan, seperti Trillion Dollar Security Initiative dari Ethereum Foundation. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) Pertanyaan berikutnya yang harus diajukan adalah apakah investasi tersebut dapat diubah menjadi infrastruktur publik yang juga dapat diadopsi dan diperiksa oleh tim lain.Tidak satu pun dari tujuh item pekerjaan ini dapat menjamin keamanan absolut. Yang perlu mereka hasilkan adalah batas-batas yang dapat diperiksa: dalam kondisi kompromi izin apa, berapa banyak aset yang paling banyak terekspos, seberapa cepat anomali dapat ditemukan, dan kepada siapa pemulihan masih bergantung.
Pada titik ini, sebagian orang mungkin berkata: arahnya terdengar benar, tetapi industri sudah berjalan selama bertahun-tahun; berapa banyak orang dan berapa banyak waktu yang dibutuhkan untuk rekonstruksi? Bukankah ini masih idealisme?
Jika diperkirakan menurut mode produksi perangkat lunak masa lalu, keraguan ini sangat realistis. Tetapi pada tahun 2026, saya percaya coding agent dan rekayasa perangkat lunak yang didukung AI telah mengubah kapasitas konstruksi yang dapat kita kerahkan. Coding agent yang dimaksud di sini adalah asisten pemrograman AI yang dapat membaca dan menulis kode, memanggil alat, menjalankan pengujian, dan terus bekerja berdasarkan umpan balik di lingkungan pengembangan. Pembangun menetapkan tujuan, mendefinisikan batas keamanan, menggunakan alat-alat ini untuk mengimplementasikan dan memeriksa sistem, serta bertanggung jawab atas hasilnya.
Pekerjaan yang sebelumnya memerlukan tim besar untuk berulang kali mengimplementasikan, mengadaptasi, dan memelihara kini dapat dicoba oleh tim kecil dengan pendekatan rekayasa baru ini. Satu tim memegang satu lapisan, menyerahkan komponen di sekitar antarmuka yang jelas, lalu tim lain memeriksa dan menggabungkannya. Mengorganisasi pertimbangan arsitektur manusia, kapasitas implementasi coding agent, dan verifikasi keamanan independen adalah, menurut pandangan saya, jalur konstruksi yang layak untuk dinilai kembali secara serius.
Penelitian oleh Anthropic dan PNNL memberikan contoh konkret: dalam lingkungan simulasi infrastruktur kritis yang terbatas, para peneliti melaporkan bahwa rekonstruksi serangan dipersingkat dari yang mungkin beberapa minggu menjadi sekitar tiga jam. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Ini tidak dapat membuktikan bahwa tim kecil sudah dapat menulis ulang seluruh industri dengan aman, tetapi ini menunjukkan bahwa pekerjaan verifikasi dan pertahanan-serangan yang sebelumnya mahal dapat memiliki kondisi biaya baru.
Salah satu pendekatan organisasi yang dapat dimulai sekarang adalah bersama-sama membangun Build in Public AI Factory. Pakar industri, akademisi, dan praktisi secara terbuka menulis persyaratan dan spesifikasi penerimaan (spec), menjelaskan apa yang akan dilindungi, operasi mana yang diizinkan, dan batas apa yang harus tetap berlaku setelah izin mana yang dikompromikan, lalu mengubah persyaratan ini menjadi pengujian penerimaan. Kelompok coding agent mengambil alih pekerjaan utama pengkodean, pengujian, dan debugging; tim yang berbeda memeriksa desain dan hasil, dan manusia memikul tanggung jawab penilaian dan penerimaan.Peserta dapat menyumbangkan ide, mesin, daya komputasi, dan kuota pemanggilan model, yaitu token AI. Perusahaan AI dan komputasi awan juga dapat mendukung pembangunan publik ini melalui kuota model, sumber daya komputasi, dan alat. Spesifikasi, kode prototipe, alur kerja agen, lingkungan pengujian, dan hasil verifikasi semuanya dapat menjadi infrastruktur yang dipelihara bersama, memungkinkan tim berikutnya untuk melanjutkan langsung dari sana. Tujuannya adalah membangun kapasitas pengembangan menjadi fasilitas publik yang dapat digunakan kembali dan mengurangi ketergantungan pada waktu satu orang atau satu tim mana pun.
Penyerang juga menggunakan AI, dan kita tidak lagi punya alasan untuk meninggalkan pertahanan pada metode produksi masa lalu. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Tetapi pembuatan kode yang cepat hanyalah titik awal. Hanya dengan menulis batasan secara jelas, membuat pengujian dapat dijalankan berulang kali, dan membuat komponen dapat diperiksa dan diganti, kemampuan AI dapat diubah menjadi peningkatan infrastruktur.
Pembangun independen bekerja sama dengan bantuan agen pengkodean dan alat AI. Lokakarya ruang angkasa adalah metafora untuk pembangunan publik. Saya terutama ingin menyampaikan seruan ini kepada mereka yang masih mencintai membangun. "Hacker" di sini mengacu pada seseorang yang bersedia mencari tahu bagaimana suatu sistem bekerja, bersedia membagikan apa yang mereka temukan, dan bersedia membiarkan orang lain menguji karya mereka. Semangat itu pernah mendorong Internet maju, dan hari ini dapat mendorong Crypto maju juga.
Saya tidak percaya industri ini kekurangan orang pintar, dan saya tidak percaya industri Crypto dan AI tidak dapat menemukan sumber daya untuk mendukung pekerjaan ini. Yang lebih sulit adalah mengorganisasi bakat, pendanaan, dan tanggung jawab yang berkelanjutan bersama-sama. Yayasan dan perusahaan yang mampu harus bersedia menanggung biaya jangka panjang untuk pekerjaan fondasional yang tidak langsung menghasilkan pendapatan tetapi bermanfaat bagi semua orang.
Saya berharap semua orang dapat bekerja sama untuk membangun infrastruktur kriptografis yang dibagikan secara global. Jaringan dan tim yang berbeda dapat berkolaborasi di bawah batasan keamanan bersama, masing-masing menerapkan solusi mereka sendiri dan menguji milik satu sama lain, dan pengguna dapat memilih dan bermigrasi. Ini dapat dimulai dengan satu komponen, tetapi arahnya harus cukup besar untuk menampung seluruh industri yang membangun bersama. Semua peserta, termasuk ArcBlock, harus menyumbangkan pekerjaan yang dapat diverifikasi.
Kita harus bersama-sama membangun semacam infrastruktur di mana, bahkan jika beberapa bagian telah disusupi, aset masih memiliki batas, sistem lain masih dapat menolak kesalahan, dan pengguna masih memiliki jalur untuk pemulihan dan keluar. Meminjam nama dari Star Wars, ini adalah A New Hope kita. [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) Harapan itu datang dari pembangun biasa yang bersedia bertindak, dan juga dari momen ini ketika agen pengkodean dan metode rekayasa baru memungkinkan mereka untuk mengambil lebih banyak pekerjaan pembangunan.Saya ingin menyampaikan undangan kepada para pembangun proyek seperti Ethereum, Solana, Bitcoin, dan XRP Ledger, kepada bursa seperti Binance, Coinbase, dan Kraken, serta kepada tim dompet, protokol, riset keamanan, AI, dan komputasi awan: mulailah dengan pilot yang cakupannya jelas dan bersama-sama hasilkan perbaikan yang dapat diadopsi dan diuji oleh tim lain.
Nama-nama yang disebutkan hanyalah contoh, tanpa urutan tertentu. Terlepas dari ukuran atau jalur teknis yang Anda ambil, Anda dipersilakan untuk berpartisipasi. Undangan ini juga mencakup para pembangun jalur teknis yang dikritik dalam artikel ini; bersama-sama meningkatkan keamanan aset layak melampaui batas ekosistem masing-masing.
Saya sendiri bersedia berpartisipasi dan menyumbangkan infrastruktur, rekayasa perangkat lunak, dan praktik kolaborasi AI yang kami miliki. Kami hanyalah tim kecil di industri ini, dan apa yang dapat kami lakukan terbatas. Saya berharap dapat memulai dengan prototipe dan serangkaian pengujian yang dapat diulang.
Orang-orang dengan pengalaman operasional praktis dapat menyediakan skenario serangan yang telah dianonimkan, tim dompet dan protokol dapat mengimplementasikan perlindungan, dan peneliti independen dapat mencoba melewatinya. Setiap tim mengambil bagian yang dapat ditanganinya, bersama-sama menguji solusi dan memutuskan langkah berikutnya.
Saya bersedia berpartisipasi dalam mengorganisir persyaratan pembatasan dan pemulihan aset dalam artikel ini menjadi spesifikasi publik pertama, dan saya juga bersedia menyumbangkan praktik teknis dan rekayasa yang relevan untuk membangun, bersama dengan peserta lain, sebuah AI Factory publik untuk pilot ini. Pertama pilih masalah yang sangat spesifik: setelah kunci transaksi sehari-hari telah dikompromikan, bagaimana penyerang masih dapat dicegah menguras dompet sekaligus? Tuliskan rentang kerugian yang diizinkan, otoritas untuk mengubah aturan, dan kondisi pemulihan ke dalam pengujian penerimaan, lalu minta agen pengembangan mengimplementasikan prototipe, dan minta kelompok agen lain serta peneliti independen mencari jalur bypass. Server data yang mengembalikan saldo yang salah, dan pemulihan setelah kehilangan perangkat, juga dapat secara bertahap ditambahkan ke pengujian. Apa yang dicapai prototipe, di mana ia gagal, dan dependensi apa yang tersisa harus dijelaskan secara publik, dan langkah berikutnya harus diputuskan berdasarkan bukti.
Mereka yang bersedia berpartisipasi dipersilakan untuk memposting ulang atau mengutip inisiatif ini secara publik di X dan @mave99a, dan membicarakan masalah yang ingin Anda selesaikan, kasus serangan yang telah dianonimkan, atau sumber daya yang dapat Anda sumbangkan. Saya berharap diskusi berlangsung secara publik, sehingga lebih banyak pembangun dapat melihatnya dan bergabung.
Crypto tidak bisa terus seperti ini. Mereka yang bersedia bekerja sama, mari kita bertindak sekarang, dimulai dengan satu perbaikan yang dapat dibangun dan dapat bertahan dalam pengujian.Binance, pengumuman awal pos resmi dan pembaruan resmi investigasi lanjutan, 2026-10-30; analisis multi-rantai TRM. Draf ini diverifikasi per 2026-10-30; status investigasi dan pemulihan dapat berubah. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. Konsentrasi risiko dari dependensi bersama adalah penilaian penulis dalam artikel ini, bukan kesimpulan dari dokumen tersebut. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, dibuat 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, pracetak arXiv v1; bukan identifikasi atas insiden Binance ini. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), mekanisme pengurutan, berbagai jenis, dan dampak negatifnya; "harus diperbaiki sebagai bug" adalah posisi engineering penulis terhadap perilaku yang merugikan pengguna. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Arsip berita resmi PHP 2026; pembaruan Known Exploited Vulnerabilities CISA 2026-10-26, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, deskripsi fungsionalitas dan risiko izin. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; deskripsi dukungan parts pairing saat ini. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, pernyataan vendor mengenai serangan dalam rantai distribusi; Joe Grand, penelitian reverse engineering tentang hardware implant. Jangan menyajikan estimasi kerugian jaringan yang belum terverifikasi sebagai kesimpulan definitif. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, diakses 2026-10-30, catatan insiden Juli 2026 dan remediasi yang diperbarui secara berkelanjutan; peningkatan versi dan migrasi seed adalah dua operasi yang berbeda. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, pemulihan ambang batas, kompatibilitas, dan risiko passphrase tambahan. Mekanisme yang ada adalah fondasi untuk membangun, dan tidak berarti setiap penerapan dapat diandalkan. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: Format Transaksi Bitcoin yang Ditandatangani Sebagian, format pertukaran untuk transaksi yang belum ditandatangani, bukan spesifikasi strategi aset umum lintas rantai. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, Catatan Grup 2026-07-30; catatan privasi Ethereum. Status standar teknologi yang dijelaskan dalam ikhtisar tersebut bersifat independen dalam setiap kasus. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Dokumentasi CoW Protocol, intensi transaksi dan mekanisme solver; artikel ini tidak memberikan dukungan keamanan yang komprehensif untuk penerapan tertentu mana pun. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, Laporan Tahunan IBIT 2025, halaman PDF 8–10 pengaturan kustodian dan halaman 45 pengungkapan risiko. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Sentralisasi, Desentralisasi, dan Standar Internet, 2023-12, diajukan secara independen, RFC informasional, bukan spesifikasi jalur standar. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bagian 8 whitepaper Bitcoin Verifikasi Pembayaran Sederhana; BIP-157: Penyaringan Blok Sisi Klien; Ethereum, Klien ringan. Klien ringan yang berbeda memiliki cakupan verifikasi dan kondisi kepercayaan yang berbeda. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Mengumumkan Inisiatif Keamanan Triliun Dolar, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI untuk mempertahankan infrastruktur kritis, 2026-01-08, penelitian lingkungan terbatas bekerja sama dengan PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Memetakan ancaman siber yang dimungkinkan AI, penelitian atas sampel penyalahgunaan aktual. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; artikel ini meminjam judul dan citra penyelamatan diri bersama. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)