Crypto Tidak Bisa Begini Lagi: Sebuah Surat Inisiatif untuk Menyelamatkan Industri dari Seorang Praktisi Blockchain

Penulis: Robert Mao, Pendiri dan CEO ArcBlock

Artikel ini diizinkan untuk disalin dan diteruskan oleh siapa saja, dengan harapan lebih banyak orang dapat melihat seruan penyelamatan industri ini.

Crypto tidak bisa begini lagi. Pencurian besar-besaran yang terjadi berulang kali tidak hanya merampas aset, tetapi juga kepercayaan para peserta terhadap seluruh industri. Kita harus menyelamatkan diri sendiri.

Pada 29 Oktober 2026, Binance mengalami insiden keamanan besar. Pengumuman awal memperkirakan sekitar 6,3 miliar dolar AS aset terpengaruh, dengan sekitar 3 miliar dolar AS aset yang terpengaruh telah dibekukan; penyelidikan awal mengarah pada laptop insinyur DevOps, dan kemudian ditemukan titik masuk lain yang mungkin. Binance juga menyatakan bahwa belum ada bukti kebocoran kunci pribadi dompet. Jumlah yang terpengaruh bukanlah kerugian bersih akhir, dan rantai serangan lengkap masih dalam penyelidikan.

Inisiatif ini ditujukan kepada para pembangun proyek blockchain seperti Ethereum dan Solana, serta kepada Binance, Coinbase, Kraken, dan semua bursa, dompet, protokol, dan pembangun keamanan yang bersedia berpartisipasi: Mari kita bersama-sama membangun kembali fondasi perlindungan aset. Saya bersedia berpartisipasi dan berharap lebih banyak orang akan bertindak bersama.

Ini sudah cukup berat. Namun, saya lebih khawatir tentang berapa banyak orang yang akan kehilangan kepercayaan terhadap Crypto setelah insiden ini, dan berapa banyak penyerang yang akan melihat industri ini sebagai target yang layak untuk dilanjutkan. Bahkan jika akhirnya ada yang menanggung kerugian, kompensasi tidak dapat secara otomatis memperbaiki kepercayaan pengguna, dan tidak dapat menghentikan kerusakan yang sama dari terjadi.

Binance hanyalah pintu masuk yang memaksa kita untuk menghadapi masalah hari ini. Jika kita mengalihkan pandangan, bursa, jembatan, protokol on-chain, dan dompet telah meninggalkan jejak luka yang panjang. Jaringan dan produk baru terus muncul, tetapi pola kegagalan lama terus terulang. Kita tidak bisa hanya mengeluarkan pengumuman, menunggu sejenak, dan kemudian menganggap insiden berikutnya sebagai hal biasa.

Kita juga harus mengakui bahwa penipuan dan praktik yang hanya menciptakan konsep tanpa bertanggung jawab atas pembangunan telah merugikan industri ini terlalu lama. Tim yang serius dalam teknologi dan infrastruktur juga harus bersama-sama menanggung konsekuensi dari hilangnya kepercayaan. Ketika orang mulai melihat seluruh Crypto sebagai penipuan, teknologi dan eksplorasi yang benar-benar layak untuk dipertahankan juga mungkin akan ditinggalkan.

Sebagai pendiri ArcBlock dan seorang praktisi Crypto dan Blockchain, saya tidak ingin menerima akhir seperti itu. Saya percaya bahwa industri ini memiliki nilai yang layak untuk dilindungi, dan saya juga percaya bahwa kita harus bertanggung jawab atas fondasi keamanan kita sendiri. Jika kita terus menunggu secara pasif untuk insiden berikutnya, kehilangan darah berulang kali pada akhirnya dapat menghancurkan semua yang telah kita bangun bersama.

Oleh karena itu, saya ingin mengeluarkan inisiatif ini: Para pembangun bursa, dompet, dan blockchain harus bersama-sama membangun kembali fondasi kontrol aset dan verifikasi keamanan, sehingga dampak dari satu kali peretasan dapat dibatasi. Garis waktu di bawah ini menjelaskan mengapa perubahan harus dilakukan; solusi teknis di belakang adalah pekerjaan yang saya rasa dapat dimulai.

Garis Waktu Insiden Ini Sudah Terlalu Panjang

Pada tahun 2008, Satoshi Nakamoto mengusulkan sistem uang elektronik peer-to-peer, berusaha mengurangi ketergantungan pada perantara yang dipercaya.

Insiden besar setelahnya terus mengungkap masalah konsentrasi kembali dari dana, otorisasi, dan ketergantungan perangkat lunak.

Berikut adalah daftar peristiwa representatif di bidang bursa terpusat (CEX), bursa terdesentralisasi (DEX), jembatan, dan dompet, disusun berdasarkan waktu. Ini bukanlah database insiden yang lengkap, dan juga bukan statistik kerugian tahunan. Jumlah yang dicantumkan, jika ada, menunjukkan dampak kasar yang mendekati saat insiden; pencurian, pembekuan, dan pemulihan selanjutnya dijelaskan secara terpisah dan tidak dapat dijumlahkan sebagai kerugian permanen.

2008 · Buku Putih Bitcoin

• Titik Awal
• Buku putih Bitcoin mengusulkan pembayaran peer-to-peer tanpa perantara keuangan.
• Sumber

2011--2014 · Pencurian Jangka Panjang Mt. Gox

• CEX
• Mt. Gox mengalami pencurian jangka panjang dan akhirnya berhenti beroperasi. Tuntutan hukum yang diajukan oleh Departemen Kehakiman AS kemudian menuduh bahwa sekitar 647.000 BTC dicuri antara 2011-2014. Ini bukanlah serangan yang terjadi dalam satu hari pada tahun 2014.
• Sumber

2012 · Bitcoinica dan Bitfloor

• CEX / Infrastruktur Terkelola
• Lingkungan hosting Linode Bitcoinica diretas; pada tahun yang sama, cadangan dompet Bitfloor yang tidak terenkripsi menjadi titik masuk serangan. Server dan cadangan di belakang platform juga merupakan batas keamanan aset.
• Sumber

2015 · Dompet Panas Bitstamp

• CEX
• Dompet panas Bitstamp diretas, kemudian lingkungan operasional dibangun kembali. Pihak resmi membedakan antara ruang lingkup insiden dan cadangan offline, menunjukkan bahwa isolasi dapat membatasi ruang paparan.
• Sumber

2016 · Bitfinex

• CEX
• Sekitar 120.000 BTC dicuri dari Bitfinex. Pengaturan multi-tanda tangan masih memerlukan otorisasi dan verifikasi independen dari ujung ke ujung.
• Sumber 1 · Sumber 2

2016 · The DAO

• Protokol On-Chain
• Kontrak The DAO mengalami serangan reentrancy, sekitar 3,6 juta ETH dipindahkan ke sub DAO, yang kemudian memicu fork Ethereum. Jalur eksekusi yang sah dapat menghasilkan hasil bisnis yang bencana.
• Sumber 1 · Sumber 2

2017 · Perpustakaan Dompet Bersama Parity

• Dompet Kontrak
• Perpustakaan dompet bersama Parity dihancurkan, sekitar 513.000 ETH dibekukan. Tidak dipindahkan, tetapi mungkin kehilangan kemampuan penggunaan karena ketergantungan kode bersama.
• Sumber

2018 · Coincheck

• CEX
• Dompet panas NEM Coincheck dicuri. Batas antara cadangan offline, izin dompet panas, dan kebutuhan bisnis kembali menjadi masalah.
• Sumber

2019 · Binance

• CEX
• Binance mengumumkan 7.000 BTC dicuri dalam satu transaksi. Aliran aset besar-besaran perlu dibatasi sebelum tanda tangan.
• Sumber

2020 · KuCoin

• CEX
• Insiden dompet panas KuCoin, yang kemudian berhasil memulihkan banyak aset melalui kolaborasi multi-pihak. Jumlah yang dicuri dan kerugian akhir bukanlah angka yang sama.
• Sumber

2021 · Poly Network

• Protokol Lintas Rantai
• Sekitar 612 juta dolar AS aset Poly Network dipindahkan, kemudian dikembalikan secara bertahap. Otorisasi lintas rantai dan kontrol aset tidak dapat hanya bergantung pada jalur bisnis normal.
• Sumber

2022 · Jembatan Ronin

• Jembatan
• Otoritas validator Ronin diretas, 173.600 ETH dan 25,5 juta USDC dipindahkan. Kunci dari beberapa validator juga mungkin jatuh ke dalam rantai serangan yang sama.
• Sumber

2022 · Dompet Slope

• Dompet
• Insiden dompet Slope di ekosistem Solana. Pihak resmi Solana menunjukkan bahwa informasi kunci pribadi secara tidak sengaja dikirim ke layanan pemantauan aplikasi; bukan karena konsensus Solana yang diretas.
• Sumber

2023 · Euler

• Protokol Pinjaman
• Sekitar 197 juta dolar AS aset Euler dipindahkan karena kerentanan protokol, kemudian dipulihkan. Kombinasi kompleks dari transaksi tunggal dapat memperbesar cacat logika bisnis.
• Sumber

2023 · Kit Koneksi Ledger

• Alat Koneksi Dompet
• Kit Koneksi Ledger mengalami serangan rantai pasokan, kode jahat masuk ke frontend aplikasi. Keamanan perangkat keras tidak dapat menggantikan verifikasi konten transaksi.
• Sumber

2024 · DMM Bitcoin

• CEX
• Sekitar 308 juta dolar AS dicuri dari DMM Bitcoin. FBI dan lembaga lain kemudian mengungkap serangan rekayasa sosial terhadap individu terkait dan jalur tanda tangan.
• Sumber

2024 · Radiant Capital

• Protokol Pinjaman / Tanda Tangan
• Sekitar 50 juta dolar AS dicuri dari Radiant Capital, beberapa perangkat pengembang diretas. Tanda tangan bersama masih dapat bergantung pada informasi transaksi yang terkontaminasi.
• Sumber

2025 · Bybit / Safe

• CEX / Frontend Dompet
• Insiden sekitar 1,5 miliar dolar AS di Bybit, serangan melibatkan lingkungan pengembang Safe dan frontend, penandatangan menyetujui transaksi yang mengubah logika kontrol dompet.
• Sumber 1 · Sumber 2

2025 · Cetus DEX

• DEX
• Insiden sekitar 223 juta dolar AS di Cetus di Sui, peneliti menunjukkan cacat pada pustaka matematika. Lingkungan non-EVM juga harus memeriksa kode dan ruang paparan aset.
• Sumber

2026-07 · Cacat Angka Acak COLDCARD

• Dompet Keras / Generasi Benih
• Cacat firmware melemahkan generasi benih, penyerang dapat membangun kunci pribadi terkait saat perangkat offline. Pembaruan tidak dapat memperbaiki benih lemah yang sudah dihasilkan, masih perlu migrasi sesuai pengumuman.
• Sumber

2026-10 · Penanaman Perangkat Ledger

• Dompet Keras / Serangan Distribusi
• Ledger mengonfirmasi bahwa perangkat asli telah dimodifikasi dan beredar melalui saluran distribusi di Asia Tenggara, komponen yang ditanam mencuri frasa pemulihan saat inisialisasi. Pabrikan menyatakan bahwa chip, sistem operasi, dan servernya tidak diretas.
• Sumber

2026 · Insiden Multi-Rantai Binance

• CEX / Multi-Rantai
• Binance memperkirakan sekitar 6,3 miliar dolar AS aset terpengaruh, penyelidikan terhadap titik masuk lain masih berlangsung. Sistem operasi tunggal dapat membuat aset di beberapa jaringan terpapar secara bersamaan.
• Sumber 1 · Sumber 2 · Sumber 3

Di sini ada CEX, juga ada bursa terdesentralisasi, protokol pinjaman, dan jembatan; ada aset yang dicuri, juga ada aset yang dibekukan. Serangan terjadi di berbagai lapisan, dan metode perbaikan juga berbeda. Saya menolak untuk menyimpulkan semua ini dengan kalimat "pengguna tidak menjaga kunci pribadi dengan baik". Bagaimana pengguna bisa tahu bahwa lingkungan pengembangan alat tertentu, pustaka bersama tertentu, atau otorisasi yang tidak dimengerti dapat menjadi pintu masuk untuk semua aset mereka?

Jaringan terdistribusi telah melakukan banyak hal, tetapi isolasi kesalahan dalam kontrol aset masih jauh dari cukup. Eksekusi on-chain menyelesaikan transaksi dengan setia, tetapi tidak dapat menjawab mengapa transaksi ini memiliki hak untuk memindahkan begitu banyak barang.

Mari Berbagai Jalur Teknologi Bersama-sama Membangun Fondasi Keamanan

Kontribusi Ethereum sangat besar. Ini memungkinkan lebih banyak orang untuk menulis aplikasi di blockchain, membentuk alat dan pengalaman pengembangan yang kaya. Namun hari ini, banyak rantai baru dan L2 (jaringan skala lapisan kedua) menjadikan kompatibilitas EVM sebagai tujuan utama. EVM, yang merupakan mesin virtual untuk mengeksekusi kontrak pintar Ethereum, sedang menjadi prasyarat teknologi yang banyak disalin. Kompatibilitas memang memudahkan migrasi aplikasi; dokumentasi proyek seperti Unichain secara jelas menyatakan bahwa penggunaan kembali alat Ethereum adalah nilai dari lingkungan eksekusi yang setara.

Saya percaya bahwa menjadikan kompatibilitas EVM sebagai jawaban default industri sedang menciptakan risiko struktural yang terkonsentrasi. Nama jaringan bisa banyak, validator juga bisa berbeda, tetapi pengembang mungkin berulang kali menerapkan kontrak yang sama, menggunakan kebiasaan otorisasi yang sama, dan bergantung pada pustaka perangkat lunak yang sama. Kesalahan dalam ketergantungan bersama tidak akan hilang hanya karena diterapkan di rantai lain. Ini adalah penilaian terhadap jalur teknologi, bukan berarti setiap implementasi EVM pasti memiliki celah yang sama.

Kritik saya terhadap Ethereum juga terletak di sini. Kemampuan eksekusi kontrak yang umum langsung menghubungkan aset yang dapat dipindahkan, memberikan tanggung jawab besar kepada kode aplikasi dan interaksi dompet. Kontrak dapat memanggil kontrak, otorisasi dapat ada dalam jangka panjang, dan konfirmasi yang tampaknya biasa dapat mengubah cara kontrol akun di masa mendatang. Keamanan semakin bergantung pada pemahaman yang benar dari setiap tim pengembang tentang kombinasi ini, serta pemahaman yang benar dari setiap pengguna tentang apa yang mereka tanda tangani.

EIP-7702 menunjukkan masalah ini dengan sangat jelas. Transfer biasa adalah "berapa banyak yang ditransfer kepada siapa"; otorisasi delegasi mungkin adalah "biarkan kode ini melakukan operasi atas nama akun saya di masa depan". Ini bertujuan untuk meningkatkan pengalaman pengguna dan membagi otoritas, tetapi pengaturan delegasi itu sendiri memberikan kemampuan eksekusi yang luas, dan otoritas yang lebih rinci harus diimplementasikan dengan benar oleh kode delegasi. Preprint oleh Minfeng Qi dan lainnya, "EIP-7702 Phishing Attack", meneliti jalur untuk mempertahankan kontrol akun setelah menandatangani otorisasi semacam ini. Ketika kenyamanan meningkat, tanggung jawab keamanan juga meningkat, dan tidak bisa hanya diserahkan kepada pengguna.

Insiden Binance kali ini melintasi beberapa rantai, dan penyelidikan belum selesai, jadi tidak bisa langsung mengaitkan semua dampak dengan EIP-7702 atau EVM. Reentrancy, layanan tanda tangan yang terkompromi, dan modifikasi frontend bukanlah celah yang sama. Namun, perbedaan ini tidak seharusnya menjadi alasan untuk berhenti mempertanyakan arsitektur: mengapa lapisan dasar tidak menyimpan lebih banyak batasan yang tidak mudah dilanggar untuk kesalahan lapisan atas?

MEV juga membuat saya tidak puas. Ini merujuk pada ruang di mana peserta memanfaatkan inklusi, eksklusi, dan pengurutan transaksi untuk mendapatkan nilai tambahan. Bagi saya, memanfaatkan kekuasaan pengurutan untuk menyerang transaksi pengguna dan memperburuk hasil mereka harus dianggap sebagai bug yang perlu diperbaiki, tidak bisa karena ada yang bisa menghasilkan uang dari situ, lalu dibungkus sebagai fitur yang layak dipertahankan. Dokumentasi Ethereum sendiri juga mengakui kerugian yang ditimbulkan oleh serangan transaksi terhadap pengguna, serta risiko MEV terhadap stabilitas jaringan. MEV bukanlah milik eksklusif Ethereum, juga mencakup berbagai aktivitas seperti arbitrase dan likuidasi; industri telah melakukan penelitian untuk mengurangi dampaknya. Kritik saya adalah bahwa insentif untuk memelihara jaringan tidak boleh menjadi alasan untuk mengorbankan kondisi transaksi pengguna. Sistem transaksi yang lebih baik harus memasukkan hasil penyelesaian minimum dan biaya yang diizinkan ke dalam otorisasi, dan membatasi ruang bagi pengurut untuk memanfaatkan informasi transaksi yang belum selesai untuk merugikan pengguna.

Saya selalu merasa bahwa pengaruh Ethereum terhadap Crypto mirip dengan PHP terhadap internet: ia memungkinkan banyak orang untuk membuat sesuatu, tetapi juga meninggalkan utang teknik yang perlu dibayar dalam jangka panjang. PHP masih perlu memperbaiki kerentanan eksekusi kode jarak jauh yang serius pada Oktober 2026. Kedewasaan dan penyebaran tidak dapat menggantikan penguatan yang berkelanjutan. Keberadaan internet yang berharga terletak pada evolusi bahasa, kerangka kerja, dan layanan cloud yang dapat berkembang secara terpisah. Kita juga harus memungkinkan model aset dan cara eksekusi yang berbeda untuk terus berkembang, bukan menjadikan "kompatibilitas dengan mesin virtual yang sama" sebagai tiket untuk berpartisipasi dalam ekosistem.

Oleh karena itu, saya menyerukan kepada ekosistem Bitcoin, Solana, Ripple/XRP Ledger, serta para pembangun termasuk ArcBlock, untuk secara serius berpartisipasi dalam pembangunan fondasi keamanan bersama. Partisipasi dalam standar dan interoperabilitas tidak harus mengubah diri menjadi Ethereum terlebih dahulu. Keberagaman harus diwujudkan dalam kontrol aset dan cara verifikasi, serta menerima pemeriksaan publik. Insiden Slope dan Cetus telah mengingatkan kita bahwa non-EVM juga tidak memiliki pengecualian keamanan.

Saya berharap dapat membentuk norma keamanan yang dapat diterapkan oleh berbagai lingkungan eksekusi: batasan aset dan persyaratan verifikasi yang sama dapat diimplementasikan oleh EVM dan jalur lainnya, dan kemudian mempublikasikan jaminan dan biaya masing-masing.

Tujuh Langkah untuk Memperkuat Keamanan

1. Membuat Pembatasan Manajemen Risiko Dasar untuk Hak Pengelolaan Aset

Dompet besar harus dapat mengatur daftar putih penerima, batas pengeluaran kumulatif, serta periode tunggu untuk penerima baru. Kuncinya adalah, aturan-aturan ini tidak boleh dapat dibatalkan segera oleh kunci transaksi sehari-hari yang sama. Mengubah aturan memerlukan otorisasi independen, dan juga harus memberikan waktu untuk pemantauan dan pembatalan.

Akun pintar yang ada sudah memiliki dasar implementasi, misalnya Safe Guards dapat menambahkan batasan transaksi di luar multi-signature. Kita perlu menjadikannya kemampuan dasar yang lebih mudah diadopsi dan dapat mencakup semua jalur kontrol aset. Hanya membatasi transfer langsung, tetapi memungkinkan untuk melewati melalui otorisasi tanpa batas, modul, atau peningkatan, perlindungan akan menjadi tidak berarti. Apakah kontrak daftar putih dapat ditingkatkan, apakah ada perubahan pada hak penerima, juga harus masuk dalam ruang lingkup verifikasi.

Activation Lock Apple memberikan inspirasi dalam kehidupan sehari-hari: membatasi aktivasi ulang perangkat yang dicuri, dan membatasi kalibrasi beberapa komponen yang dicuri, tujuannya adalah untuk mengurangi nilai yang dapat dimanfaatkan setelah dicuri. Dompet juga layak dirancang ke arah ini. Jika penyerang mendapatkan satu kunci, jangkauan aset yang dapat dimanfaatkan tetap terbatas, maka potensi keuntungan dari serangan mungkin menurun; risiko seperti layanan yang terganggu masih perlu ditangani secara terpisah.

Ini adalah apa yang saya sebut "konstitusi" keamanan aset: hak operasi dapat terkompromi, tetapi hak untuk mengubah batasan tetap harus independen. Proses pemulihan juga harus terikat, untuk mencegah konfigurasi yang salah secara permanen mengunci aset.

2. Membuat Dompet Menanggung Tanggung Jawab Keamanan, dan Tidak Hanya Menyerahkan Frasa Pemulihan

Saya sangat tidak puas dengan sistem dompet saat ini: jika suatu produk meminta orang biasa untuk menyalin satu set kata, mengharuskan mereka untuk tidak pernah membocorkan, tidak boleh hilang, tidak boleh tertipu, dan kemudian semua kegagalan selanjutnya disalahkan kepada pengguna, saya percaya ini adalah desain yang tidak bertanggung jawab. Penyimpanan mandiri harus memberikan kontrol kepada orang, tetapi juga harus memberikan perlindungan dan kemampuan pemulihan yang dapat digunakan. Itu tidak seharusnya mengharuskan setiap pengguna untuk menjadi ahli keamanan terlebih dahulu. Ini juga merupakan hambatan yang harus dilalui Crypto untuk menjangkau lebih banyak pengguna biasa.

Insiden terbaru menempatkan masalah ini dengan sangat langsung. Ledger pada Oktober 2026 mengkonfirmasi bahwa penyerang memodifikasi perangkat asli, lalu mengirimkannya kembali ke pasar melalui saluran distribusi di Asia Tenggara, menyisipkan komponen yang mencuri frasa pemulihan saat inisialisasi. Ledger mendefinisikannya sebagai serangan distribusi lokal setelah perangkat keluar dari pabrik, bukan karena chip, sistem operasi, atau servernya diretas. Insiden COLDCARD pada bulan Juli melibatkan pengurangan firmware untuk menghasilkan benih: perangkat tidak perlu dikendalikan dari jarak jauh, penyerang juga dapat membangun kunci privat terkait. Memperbarui firmware memperbaiki proses pembuatan di masa depan, tetapi benih yang sudah dihasilkan yang lemah masih perlu dipindahkan.

Kedua insiden ini bukan celah yang sama, tetapi keduanya menunjukkan: bahkan jika pengguna menyalin kata-kata dengan hati-hati dan menyimpan perangkat secara offline, mereka tidak dapat menggantikan produsen dalam memverifikasi angka acak dan rantai pasokan yang lengkap. Membiarkan perangkat menampilkan frasa cadangan memiliki kegunaan pemulihan offline, tetapi juga akan membuat rahasia pemulihan lengkap melalui jalur tampilan dan cadangan yang perlu dilindungi. Keamanan chip tidak dapat menggantikan verifikasi terhadap seluruh perangkat dan proses pengiriman.

Tujuan perbaikan harus mencakup seluruh siklus hidup dompet: bagaimana kunci dihasilkan, bagaimana transaksi dijelaskan, bagaimana otoritas dipisahkan, dan bagaimana pemulihan dilakukan setelah perangkat hilang. Abstraksi akun, yaitu memungkinkan akun untuk memverifikasi otorisasi melalui aturan yang dapat diprogram, serta cadangan ambang seperti SLIP-39, sudah memiliki standar dan dasar implementasi, tidak bisa dikatakan bahwa industri tidak ada yang melakukannya. Namun, kita perlu menjadikan kemampuan ini sebagai perlindungan yang teruji dan mudah digunakan, bukan membiarkan pengguna merakit skema yang rumit sendiri.

Kebingungan sederhana dari frasa pemulihan tidak cukup. Arah yang lebih dapat diandalkan termasuk cadangan terenkripsi yang telah diperiksa, pemulihan ambang, dan otorisasi perangkat independen, serta memungkinkan pengguna menyelesaikan latihan pemulihan sebelum menyimpan aset besar. Pembagian cadangan dan multi-signature adalah lapisan yang berbeda: yang pertama mungkin dapat menggabungkan kembali rahasia yang sama saat pemulihan, yang terakhir memerlukan persetujuan dari beberapa penandatangan independen untuk menyetujui transaksi. Layanan pemulihan tidak boleh diam-diam menjadi kunci utama baru, dan tidak boleh membiarkan kata sandi tambahan menjadi perangkap lain yang tidak dapat dipulihkan jika hilang.

Dompet pribadi dan sistem dompet bursa dapat berbagi deskripsi transaksi, permintaan tanda tangan, batasan aset, dan norma keamanan proses pemulihan, dengan menggunakan berbagai batasan dan strategi persetujuan. PSBT Bitcoin telah menyediakan format untuk mentransfer transaksi yang menunggu tanda tangan antar alat, antarmuka bersama ini layak untuk terus dibangun. Yang sama adalah persyaratan keamanan yang dapat diperiksa, setiap rantai masih perlu menjelaskan aturan penyesuaian mereka sendiri. Dompet harus jelas menunjukkan apa yang akan dipindahkan oleh tanda tangan ini, memberikan siapa berapa banyak hak lanjutan, dan menolak operasi yang melanggar oleh strategi independen; halaman konfirmasi yang lebih menarik saja tidak cukup.

3. Mengimplementasikan Verifikasi dengan Pengungkapan Minimal yang Diperlukan

Membuktikan bahwa suatu kondisi berlaku tidak selalu harus mengharuskan pengguna untuk mengungkapkan semua data dasar. Pengungkapan selektif, bukti tanpa pengetahuan, dan akses audit yang diberikan sesuai kebutuhan harus menjadi opsi normal dalam infrastruktur. Ini juga terkait dengan keamanan aset: identitas dan hubungan aset yang terbuka dapat memberikan petunjuk untuk penipuan yang terarah; data yang tidak diperlukan oleh bisnis harus diungkapkan seminimal mungkin.

Sistem kredensial yang dapat diverifikasi oleh W3C sudah memiliki jalur teknis untuk pengungkapan selektif; namun, membuktikan bahwa input itu nyata, kredensial masih berlaku, dan bagaimana status dapat dicabut masih perlu dijelaskan. Menggunakan bukti tanpa pengetahuan (ZK) juga tidak secara otomatis menyembunyikan jumlah transaksi dan hubungan, perluasan bukti dan perlindungan privasi adalah tujuan yang berbeda.

Misalnya, ketika suatu bisnis hanya perlu memverifikasi kelayakan partisipasi, pengguna dapat menunjukkan kesimpulan kelayakan yang valid yang dikeluarkan oleh lembaga tepercaya, tanpa mengungkapkan seluruh materi keuangan. Ketika perlu membuktikan bahwa nilai yang tersembunyi memenuhi syarat, maka gunakan mekanisme pembuktian yang sesuai. Sumber kredensial yang dapat dipercaya dan status pencabutan tetap harus diverifikasi.

Inisiatif saya adalah untuk menjelaskan "siapa yang perlu memverifikasi apa" terlebih dahulu, kemudian merancang data yang harus diungkapkan. Orang yang memverifikasi kelayakan mungkin hanya perlu kesimpulan kelayakan; orang yang memiliki tanggung jawab audit tertentu dapat memperoleh bukti terbatas. Pengungkapan batasan yang dapat diverifikasi harus meminimalkan informasi pribadi yang secara permanen terungkap kepada semua orang.

IV. Mengurangi Ketergantungan pada Penitipan Terpusat untuk Layanan Transaksi

Pencocokan transaksi, pencarian jalur, dan penyelesaian pengiriman aset harus dirancang secara terpisah. Layanan yang menyediakan pintu masuk transaksi harus berusaha untuk hanya mendapatkan izin yang diperlukan untuk menyelesaikan pengiriman saat ini, sehingga aset pengguna tetap berada di bawah kendali mereka pada waktu lainnya. Protokol berbasis niat transaksi yang ada telah menjelajahi sebagian jalur, industri dapat terus menyelesaikannya.

Apa yang disetujui oleh pengguna harus merupakan syarat pengiriman yang jelas, termasuk apa yang dibayarkan, setidaknya apa yang diterima, kapan berakhir, dan biaya yang diizinkan. Setelah layanan transaksi diretas, penyerang mungkin menolak layanan, tetapi tidak dapat sembarangan mengubah syarat-syarat ini. Bisnis yang masih memerlukan penitipan terpusat juga harus memisahkan cadangan dan izin operasional, membatasi paparan dompet panas dan pengisian otomatis.

IBIT adalah produk yang diperdagangkan di bursa Bitcoin dari iShares, yang diperdagangkan di pasar adalah bagiannya. Pengaturannya memberikan contoh pemisahan parsial: bagian dan Bitcoin yang mendasarinya dicatat secara terpisah, kunci pribadi terkait Vault Balance (saldo penitipan) disimpan dalam penyimpanan dingin. Perubahan catatan perdagangan bagian tidak mengharuskan Bitcoin yang mendasarinya bergerak setiap kali.

Apa yang dapat diambil adalah pemisahan antara hak perdagangan dan hak pengelolaan cadangan. Saldo Perdagangan (Trading Balance) memiliki pengaturan yang berbeda, penitipan itu sendiri juga memiliki risiko; penyimpanan dingin harus disertai dengan instruksi dan verifikasi tanda tangan yang independen.

Saya membandingkan pintu masuk transaksi dengan router, berharap itu dapat diganti tanpa membawa total saklar aset semua pengguna. Penyelesaian lebih kompleks daripada pengalihan paket data, pengiriman aset dan otorisasi masih harus diverifikasi secara independen. Setelah layanan menjadi non-penitipan, memberikan hak penarikan tak terbatas hanya akan membawa kembali risiko terpusat.

V. Menggunakan Arsitektur Berlapis untuk Mengisolasi Kegagalan dan Mempertahankan Kemampuan Penggantian

Kita perlu antarmuka identitas dan otorisasi, kebijakan aset, dan metode verifikasi penyelesaian yang dapat berkembang secara independen. Rantai yang berbeda dapat mempertahankan model eksekusi mereka sendiri, terhubung melalui antarmuka yang jelas. Antarmuka harus menjelaskan jaminan keamanan dan syaratnya, tidak hanya mengatakan "panggilan berhasil".

Pengalaman internet mendukung pemikiran ini. Mark Nottingham dalam RFC 9518 "Sentralisasi, Desentralisasi, dan Standar Internet" secara khusus membahas situasi di mana sentralisasi dapat membantu, serta menganalisis kekuasaan dan risiko yang ditimbulkannya. Ini adalah sikap yang patut dicontoh: membiarkan arsitektur menjawab tanggung jawab mana yang dapat dipusatkan, sejauh mana dapat dipusatkan, dan bagaimana mencegah perluasan kekuasaan ini. Sebuah layanan dapat secara terpusat mengidentifikasi anomali, sambil membatasi izin aksesnya ke aset; pengguna harus dapat mengganti layanan tanpa kehilangan kebijakan aset dan catatan verifikasi mereka.

Masalah penerimaan yang paling penting adalah: setelah layanan bisnis diretas, lapisan independen mana yang masih dapat menolak? Jika semua lapisan berbagi satu kunci manajemen, maka apa yang disebut pemisahan hanya menjadi pemisahan di peta penyebaran.

Kita dapat melihat tujuan ini sebagai lima tanggung jawab: layanan transaksi mengajukan permintaan, dompet mengekspresikan niat pengguna, kebijakan independen membatasi hak pengelolaan aset, komponen verifikasi memeriksa operasi dan bukti, lapisan penyelesaian mengeksekusi batasan dan menyediakan catatan yang dapat diverifikasi. Mereka dapat diimplementasikan oleh tim yang berbeda, dan juga harus menjelaskan ketergantungan dan kondisi kegagalan masing-masing.

Arsitektur tujuan yang diusulkan dalam artikel ini. Lapisan penyelesaian harus memaksa pelaksanaan kebijakan aset; petunjuk di dompet tidak dapat menggantikan batasan ini. Tanda tangan sehari-hari, perubahan aturan, dan pemulihan izin perlu diisolasi dan menerima pengujian bypass.

VI. Memungkinkan Pengguna untuk Memverifikasi Aset Mereka Secara Ringan

Orang biasa tidak seharusnya harus menyimpan dan menjalankan seluruh sejarah rantai untuk memverifikasi saldo dan penerimaan mereka; mereka juga tidak seharusnya hanya dapat mempercayai satu server di belakang dompet. Satoshi telah mengusulkan SPV, yaitu verifikasi pembayaran yang disederhanakan, di bagian delapan dari buku putihnya. BIP-157 Bitcoin terus mengeksplorasi cara agar klien dapat mengunduh filter, mencari blok yang relevan bagi mereka; Ethereum juga memiliki desain klien ringan. Jadi masalahnya bukan karena tidak ada yang pernah memikirkan hal ini, tetapi kita masih perlu membangun kemampuan verifikasi dengan syarat keamanan yang jelas ke dalam dompet yang digunakan pengguna setiap hari.

Sebagai contoh, untuk rantai yang mendukung pembuktian status akun, saat memeriksa saldo, server harus mengembalikan saldo dan pembuktian secara bersamaan. Dompet terlebih dahulu memverifikasi ringkasan blok yang singkat sesuai dengan aturan rantai ini, yaitu header blok, kemudian memeriksa apakah saldo ini konsisten dengan data yang dijanjikan oleh ringkasan tersebut. Server memberikan jawaban, dan dompet dapat memverifikasi jawaban tersebut. SPV Bitcoin memverifikasi bukti bahwa transaksi terkait telah dimasukkan, tidak dapat langsung diterapkan pada pembuktian saldo ini. Dompet juga harus secara jelas menunjukkan di mana sinkronisasi telah terjadi, informasi mana yang telah diverifikasi; ketika pembuktian hilang, data kedaluwarsa, atau sumber bertentangan, harus memberikan peringatan atau menghentikan operasi berisiko tinggi yang bergantung pada informasi ini, tidak dapat secara diam-diam kembali ke kepercayaan buta.

Verifikasi ringan masih memiliki syarat. Membuktikan bahwa suatu transaksi telah dimasukkan ke dalam blok tidak sama dengan memeriksa bahwa semua transaksi di dalam blok tersebut sah. Berbagai skema mungkin bergantung pada kejujuran mayoritas kekuatan komputasi, atau catatan awal yang tepercaya, yaitu titik pemeriksaan; juga harus mencegah server menyembunyikan data, atau mengisolasi pengguna pada catatan rantai yang kedaluwarsa. Apakah pencarian itu sendiri akan mengekspos alamat yang menjadi perhatian pengguna juga perlu ditangani. Node penuh dan pembuat blok bukanlah peran yang sama, saat ini Ethereum menggunakan validator untuk membuat blok, bukan penambang.

Lebih penting lagi, membuktikan bahwa "transfer ini memang terjadi di rantai" tidak membuktikan bahwa "ini adalah transfer yang diinginkan pengguna". Klien ringan tidak dapat menggantikan batasan aset dan pemeriksaan tanda tangan sebelumnya. Ini mengurangi ketergantungan pengguna pada jawaban yang tidak dapat diverifikasi, sementara kebijakan aset memastikan bahwa satu tanda tangan yang valid tidak dapat mengelola aset tanpa batas. Membangun kedua lapisan bersama-sama adalah cara untuk mendistribusikan kemampuan verifikasi di antara para peserta.

VII. Membangun Dasar Umum untuk Identifikasi Anomali dan Verifikasi Keamanan

Sebelum transaksi, harus ada seseorang yang memeriksa apakah operasi ini sesuai dengan kebijakan aset, apakah ada perubahan perilaku sejarah yang tiba-tiba. Anomali yang jelas dapat memicu penangguhan atau peningkatan audit; perluasan izin memerlukan jalur independen lainnya. AI dapat terlibat dalam penilaian, tetapi tidak boleh mendapatkan akses untuk melewati aturan yang ketat.

Sementara itu, kita perlu secara bersama-sama memelihara kasus serangan, pengujian izin, dan alat verifikasi yang dapat dijalankan kembali. Berbagi norma, mempertahankan implementasi independen dan verifikasi independen, dapat mengurangi kegagalan bersama. Yayasan dan bursa telah melakukan investasi keamanan, seperti Inisiatif Keamanan Triliun Dolar dari Ethereum Foundation. Langkah selanjutnya adalah mempertanyakan apakah investasi tersebut dapat diubah menjadi dasar umum yang dapat diadopsi dan diperiksa oleh tim lain.

Ketujuh pekerjaan ini tidak dapat menjamin keamanan mutlak. Apa yang mereka sampaikan adalah batasan yang dapat diperiksa: dalam kondisi izin mana yang gagal, aset paling banyak terpapar berapa banyak, seberapa lama anomali dapat terdeteksi, dan pemulihan masih bergantung pada siapa.

Rekayasa Perangkat Lunak yang Diberdayakan AI: Harapan Baru Kita

Setelah membaca ini, mungkin ada yang akan berkata: arah yang terdengar benar, tetapi industri telah berjalan selama bertahun-tahun, berapa banyak orang dan waktu yang dibutuhkan untuk membangun kembali? Bukankah ini masih idealisme?

Jika kita masih memperkirakan dengan cara produksi perangkat lunak yang lama, pertanyaan ini sangat realistis. Namun, pada tahun 2026, saya percaya bahwa agen pengkodean dan rekayasa perangkat lunak yang diberdayakan AI telah mengubah kemampuan pembangunan yang dapat kita gunakan. Yang saya maksud dengan agen pengkodean adalah asisten pemrograman AI yang dapat membaca dan menulis kode, memanggil alat, menjalankan pengujian, dan melanjutkan pekerjaan berdasarkan umpan balik. Para pembangun menetapkan tujuan, menetapkan batasan keamanan, menggunakan alat ini untuk merealisasikan dan memeriksa sistem, dan bertanggung jawab atas hasilnya.

Pekerjaan yang dulunya memerlukan tim besar untuk diimplementasikan, disesuaikan, dan dipelihara berulang kali, sekarang dapat dicoba oleh tim kecil dengan cara rekayasa baru ini. Satu tim menjaga satu lapisan, menyerahkan komponen di sekitar antarmuka yang jelas, dan kemudian tim lain memeriksa dan menggabungkannya. Mengorganisir penilaian arsitektur manusia, kemampuan implementasi agen pengkodean, dan verifikasi keamanan independen adalah jalur pembangunan yang menurut saya layak untuk dievaluasi kembali dengan serius.

Penelitian dari Anthropic dan PNNL memberikan contoh konkret: dalam lingkungan simulasi infrastruktur kunci yang terbatas, peneliti melaporkan bahwa rekonstruksi serangan yang mungkin memerlukan beberapa minggu telah dipersingkat menjadi sekitar tiga jam. Ini tidak dapat membuktikan bahwa tim kecil telah dapat menulis ulang seluruh industri dengan aman, tetapi menunjukkan bahwa biaya verifikasi dan pertahanan yang mahal di masa lalu dapat muncul dengan kondisi biaya baru.

Salah satu cara organisasi yang dapat segera diluncurkan adalah dengan bersama-sama membangun sebuah AI Factory yang dibangun secara terbuka. Para ahli industri, akademisi, dan praktisi secara terbuka menulis kebutuhan dan spesifikasi penerimaan (spec), menjelaskan apa yang perlu dilindungi, operasi apa yang diizinkan, dan batasan apa yang harus tetap dijaga meskipun izin tertentu hilang, kemudian menuliskan persyaratan ini menjadi pengujian penerimaan. Sekelompok agen pengkodean bertanggung jawab atas pengkodean utama, pengujian, dan debugging; tim yang berbeda memeriksa desain dan hasil, sementara manusia bertanggung jawab atas penilaian dan penerimaan.

Para peserta dapat menyumbangkan ide, mesin, daya komputasi, serta kuota pemanggilan model, yaitu token AI. Perusahaan AI dan cloud computing juga dapat mendukung pembangunan publik ini melalui kuota model, sumber daya komputasi, dan alat. Spec, kode prototipe, alur kerja agen, lingkungan pengujian, dan hasil verifikasi semuanya dapat menjadi dasar yang dikelola bersama, memungkinkan tim berikutnya untuk langsung melanjutkan. Tujuannya adalah untuk membangun kemampuan pengembangan menjadi fasilitas publik yang dapat digunakan kembali, mengurangi ketergantungan pada waktu seseorang atau tim tertentu.

Penyerang juga menggunakan AI, dan kita tidak lagi memiliki alasan untuk mempertahankan pertahanan dengan cara produksi yang lama. Namun, penghasil kode cepat hanya merupakan titik awal. Menulis batasan dengan jelas, memungkinkan pengujian untuk dijalankan berulang kali, dan memastikan bahwa sebuah komponen dapat diperiksa dan diganti, adalah cara untuk mengubah kemampuan AI menjadi perbaikan infrastruktur.

Para pembangun independen bekerja sama dengan agen pengkodean dan alat AI. Workshop luar angkasa adalah metafora untuk pembangunan publik.

Saya ingin mengirimkan seruan ini kepada mereka yang masih mencintai pembangunan. Hacker di sini adalah mereka yang ingin memahami bagaimana sistem bekerja, bersedia berbagi penemuan, dan juga bersedia membiarkan orang lain memverifikasi karya mereka. Semangat seperti ini pernah mendorong internet, dan hari ini juga dapat mendorong Crypto.

Saya tidak percaya bahwa industri ini kekurangan orang-orang cerdas, dan saya juga tidak percaya bahwa industri Crypto dan AI tidak dapat menemukan sumber daya untuk mendukung pekerjaan ini. Yang lebih sulit adalah mengorganisir bakat, dana, dan tanggung jawab yang berkelanjutan. Yayasan dan perusahaan yang mampu harus bersedia menanggung biaya jangka panjang untuk pekerjaan dasar yang tidak langsung menghasilkan pendapatan tetapi menguntungkan semua orang.

Saya berharap kita dapat bersama-sama menciptakan infrastruktur kripto yang dapat dibagikan secara global. Jaringan dan tim yang berbeda dapat berkolaborasi di bawah batasan keamanan yang sama, masing-masing melaksanakan dan memverifikasi satu sama lain, dan pengguna dapat memilih dan bermigrasi. Ini dapat dimulai dari satu komponen, tetapi arahnya harus cukup besar untuk menampung pembangunan bersama seluruh industri. Semua peserta, termasuk ArcBlock, harus memberikan kontribusi yang dapat diverifikasi.

Kita harus bersama-sama membangun infrastruktur: bahkan jika suatu tempat sudah hilang, aset masih memiliki batasan, sistem lain masih dapat menolak kesalahan, dan pengguna masih memiliki jalur untuk memulihkan dan pergi. Meminjam nama dari "Star Wars", ini adalah A New Hope kita. Harapan datang dari para pembangun biasa yang bersedia bertindak, serta dari agen pengkodean dan cara rekayasa baru yang memungkinkan mereka untuk mengambil lebih banyak pekerjaan pembangunan pada saat ini.

Ayo Bertindak Sekarang

Saya ingin mengundang para pembangun proyek seperti Ethereum, Solana, Bitcoin, XRP Ledger, serta bursa seperti Binance, Coinbase, Kraken, dan juga tim dompet, protokol, penelitian keamanan, AI, dan cloud computing: mulai dari pilot yang memiliki ruang lingkup yang jelas, bersama-sama membuat perbaikan yang dapat diadopsi dan diverifikasi oleh tim lain.

Daftar nama hanya sebagai contoh, tidak dalam urutan tertentu. Tidak peduli ukuran atau jalur teknologi yang diadopsi, semua orang dipersilakan untuk berpartisipasi. Undangan ini juga mencakup para pembangun dari jalur teknologi yang dikritik dalam artikel ini; bersama-sama meningkatkan keamanan aset, layak bagi kita untuk melampaui batasan ekosistem masing-masing.

Saya sendiri bersedia berpartisipasi, menyumbangkan infrastruktur, rekayasa perangkat lunak, dan praktik kolaborasi AI yang telah kami miliki. Kami hanya merupakan tim kecil dalam industri ini, dan apa yang dapat kami lakukan terbatas, berharap untuk memulai dari sebuah prototipe dan serangkaian pengujian yang dapat dijalankan kembali.

Orang-orang dengan pengalaman operasional nyata dapat menyediakan skenario serangan yang telah dianonimkan, tim dompet dan protokol dapat menerapkan perlindungan, dan peneliti independen dapat mencoba untuk menghindarinya. Setiap tim mengambil bagian sesuai kemampuan mereka, bersama-sama memverifikasi solusi, dan memutuskan langkah selanjutnya.

Saya bersedia berpartisipasi dalam menyusun batasan aset dan persyaratan pemulihan dari artikel ini menjadi spec publik pertama, serta bersedia menyumbangkan teknologi dan praktik rekayasa terkait, dan membangun AI Factory publik yang ditujukan untuk pilot ini bersama peserta lainnya. Pertama, pilih satu masalah yang sangat spesifik: kunci transaksi sehari-hari sudah hilang, bagaimana agar penyerang tetap tidak dapat mengosongkan dompet sekaligus? Tulis batasan kerugian yang diizinkan, hak untuk mengubah aturan, dan kondisi pemulihan sebagai pengujian penerimaan, kemudian biarkan agen pengembang mewujudkan prototipe, sementara sekelompok agen lain dan peneliti independen mencari jalur untuk menghindarinya. Server data mengembalikan saldo yang salah, pemulihan setelah kehilangan perangkat, juga dapat secara bertahap ditambahkan ke pengujian. Apa yang dicapai oleh prototipe, di mana kegagalan terjadi, dan ketergantungan apa yang masih ada, semuanya harus dijelaskan secara terbuka, dan langkah selanjutnya harus ditentukan berdasarkan bukti.

Siapa pun yang bersedia berpartisipasi, dipersilakan untuk membagikan atau mengutip inisiatif ini secara terbuka di X, dan @mave99a, serta menyampaikan masalah yang ingin diselesaikan, kasus serangan yang telah dianonimkan, atau sumber daya yang dapat disumbangkan. Saya berharap diskusi dilakukan secara terbuka, agar lebih banyak pembangun dapat melihat dan berpartisipasi.

Crypto tidak bisa terus seperti ini. Bagi mereka yang bersedia untuk melakukannya bersama, mari kita bertindak sekarang, mulai dari perbaikan yang dapat dilakukan dan diuji.

1. Binance, pengumuman awal pos resmi dan pembaruan investigasi resmi, 2026-10-30; analisis multi-rantai TRM. Artikel ini diverifikasi hingga 2026-10-30; status investigasi dan pemulihan dapat berubah. \↩\
2. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. \↩\
3. Uniswap, Unichain EVM Equivalence. Konsentrasi risiko yang saling bergantung adalah penilaian penulis artikel ini, bukan kesimpulan dokumen tersebut. \↩\
4. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, dibuat pada 2024-05-07. \↩\
5. Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, arXiv v1 pra-cetak; bukan penilaian insiden Binance kali ini. \↩\
6. Ethereum, nilai ekstraksi maksimal yang dapat diekstrak (MEV), mekanisme pengurutan, berbagai jenis dan dampak negatif; "seharusnya dianggap sebagai perbaikan bug" adalah klaim rekayasa penulis terhadap perilaku yang merugikan pengguna. \↩\
7. Arsip berita resmi PHP 2026; CISA 2026-10-26 pembaruan kerentanan yang diketahui dieksploitasi, CVE-2026-109618, CVE-2026-109619. \↩\
8. Safe, penjelasan risiko fungsi dan izin Guards dan Modules. \↩\
9. Apple, Apple untuk memperluas opsi perbaikan dengan dukungan untuk suku cadang asli bekas, 2024-04-11; penjelasan dukungan suku cadang terkunci saat ini. \↩\
10. Ledger, Tanggapan Ledger terhadap Serangan Implan Perangkat Keras, 2026-10, penjelasan vendor tentang serangan di tahap distribusi; Joe Grand, penelitian terbalik implan perangkat keras. Tidak menyimpulkan estimasi kerugian jaringan yang tidak diverifikasi oleh vendor. \↩\
11. Coinkite, Status Keamanan COLDCARD Saat Ini, 2026-10-30, diperiksa, catatan insiden dan perbaikan yang terus diperbarui dari Juli 2026; peningkatan dan migrasi seed adalah dua operasi yang berbeda. \↩\
12. ERC-4337: Abstraksi Akun Menggunakan Alt Mempool; Trezor, SLIP39 FAQs, pemulihan ambang, kompatibilitas dan risiko kata sandi tambahan. Mekanisme yang ada adalah dasar pembangunan, tidak berarti setiap jenis penyebaran dapat diandalkan. \↩\
13. BIP-174: Format Transaksi Bitcoin yang Ditandatangani Sebagian, format pertukaran transaksi yang belum ditandatangani, bukan spesifikasi strategi aset lintas rantai yang umum. \↩\
14. W3C, Ikhtisar Kredensial yang Dapat Diverifikasi v1.0, Catatan Grup 2026-07-30; penjelasan privasi Ethereum. Status standar teknologi yang dijelaskan dalam ikhtisar masing-masing independen. \↩\
15. Dokumen Protokol CoW, niat transaksi dan mekanisme solver; artikel ini tidak memberikan dukungan keamanan menyeluruh untuk penyebaran tertentu. \↩\
16. iShares, Laporan Tahunan IBIT 2025, PDF halaman 8-10 pengaturan kustodian dan halaman 45 penjelasan risiko. \↩\
17. Mark Nottingham, RFC 9518: Sentralisasi, Desentralisasi, dan Standar Internet, 2023-12, pengajuan independen, RFC penjelasan, bukan spesifikasi jalur standar. \↩\
18. Buku Putih Bitcoin Bagian 8 Verifikasi Pembayaran Sederhana; BIP-157: Penyaringan Blok Sisi Klien; Ethereum, Klien Ringan. Rentang verifikasi dan kondisi kepercayaan dari berbagai klien ringan berbeda. \↩\
19. Yayasan Ethereum, Mengumumkan Inisiatif Keamanan Triliun Dolar, 2025-05-14. \↩\
20. Anthropic, AI untuk mempertahankan infrastruktur kritis, 2026-01-08, penelitian lingkungan terbatas bekerja sama dengan PNNL. \↩\
21. Anthropic, Memetakan ancaman siber yang didukung AI, penelitian contoh penyalahgunaan nyata. \↩\
22. Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; artikel ini meminjam nama karya dan citra saling menyelamatkan.