Gambaran Umum Tantangan Keamanan

Salah satu fitur penentu blockchain adalah sifat atomik dari transaksi: setelah pembaruan dicatat ke dalam blockchain, tidak ada peluang untuk intervensi atau pembalikan. Ini memberikan jaminan konsistensi dan keamanan tingkat protokol yang kuat, tetapi memaparkan pengguna pada risiko operasional yang lebih tinggi: satu kesalahan, kunci yang disusupi, atau persetujuan yang terburu-buru dapat menyebabkan kerugian yang tidak dapat diubah.

Akibatnya, beban keamanan yang signifikan jatuh pada pengguna. Untuk menggunakan Ethereum dengan aman, individu dan organisasi harus memegang dan mengelola kunci dengan aman, berinteraksi dengan aplikasi onchain, dan menggunakan kunci mereka untuk menandatangani transaksi untuk mentransfer aset atau memperbarui status Ethereum.

Masing-masing persyaratan ini memperkenalkan risiko seperti kompromi atau kehilangan kunci, persetujuan yang terburu-buru atau tidak diinformasikan, atau kompromi perangkat lunak dompet yang diandalkan pengguna untuk menginformasikan dan memandu mereka melalui interaksi dengan Ethereum.

1.1 Manajemen kunci

Banyak pengguna tidak dilengkapi untuk mengelola kunci kriptografi dengan aman.

Sebagian besar dompet perangkat lunak yang banyak digunakan mengandalkan pengguna yang menyimpan frasa seed dengan aman yang mewakili kunci pribadi kriptografi yang mendasarinya, yang sering kali mengarahkan mereka untuk menggunakan solusi yang tidak aman seperti menyimpan frasa seed dalam teks biasa, di layanan cloud, atau menuliskannya di atas kertas.

Dompet perangkat keras adalah alternatif, yang memungkinkan pengguna untuk mengelola kunci kriptografi yang disimpan dalam perangkat fisik tujuan khusus. Namun, dompet perangkat keras memiliki kelemahan dan permukaan serangannya sendiri. Dompet perangkat keras dapat hilang, rusak, atau dicuri. Banyak dompet perangkat keras bukan sumber terbuka dan mungkin memiliki rantai pasokan yang tidak transparan, meningkatkan risiko serangan rantai pasokan di mana perangkat yang disusupi dijual ke pasar.

Baik kunci dikelola dalam dompet perangkat lunak atau perangkat keras, banyak pengguna dapat dimengerti merasa gugup tentang hak asuh mandiri ketika itu dapat disusupi melalui pencurian fisik atau penyerangan.

Pengguna perusahaan dan institusional menghadapi tantangan tambahan dalam manajemen kunci. Jika karyawan individu memegang kunci (misalnya, sebagai bagian dari dompet multi tanda tangan), organisasi harus dapat menggantinya dan membuat yang baru karena perubahan personel dari waktu ke waktu. Persyaratan kepatuhan di berbagai industri dan yurisdiksi mungkin memerlukan alur kerja khusus atau jejak audit yang tidak didukung oleh perangkat lunak dompet yang ada. Dalam beberapa kasus, pengguna perusahaan beralih ke kustodian pihak ketiga untuk aset digital, yang dapat memperkenalkan lapisan risiko keamanan lain untuk dipertimbangkan.

1.2 Penandatanganan buta & ketidakpastian transaksi

Pengguna secara rutin menyetujui transaksi "secara buta" tanpa memahami apa yang mereka lakukan. Dompet sering kali menyajikan data heksadesimal mentah, alamat kontrak yang terpotong, atau informasi lain yang tidak cukup bagi pengguna untuk memahami konsekuensi dari transaksi tertentu. Hal ini membuat semua jenis pengguna rentan terhadap kontrak pintar berbahaya, phishing, penipuan, antarmuka palsu, kompromi front-end, dan kesalahan dasar pengguna.

1.3 Manajemen persetujuan dan izin

Dalam banyak aplikasi Ethereum, merupakan hal yang umum bagi pengguna untuk memberikan izin tertentu ke aplikasi yang mendasarinya sebagai bagian dari penggunaan normal. Misalnya, pengguna mungkin memberikan izin kepada pertukaran terdesentralisasi seperti Uniswap untuk memindahkan token mereka guna menukarnya dengan ETH.

Persetujuan ini dapat memiliki batasan jumlah, tetapi banyak dompet secara default memberikan persetujuan tak terbatas tanpa tanggal kedaluwarsa. Tidak ada cara bagi pengguna untuk mengelola atau meninjau persetujuan mereka yang belum selesai dari dalam sebagian besar dompet.

Hal ini dapat memaparkan pengguna pada aplikasi berbahaya atau frontend yang disusupi, karena pola default bagi banyak pengguna adalah memberikan persetujuan tak terbatas yang dapat digunakan untuk menguras dana mereka. Bahkan jika pengguna memberikan persetujuan ke kontrak pintar yang sah, jika kontrak tersebut kemudian disusupi sementara persetujuan tetap berlaku, maka kontrak yang disusupi dapat menguras dana pengguna.

Ini juga merupakan risiko bagi pengguna organisasi. Misalnya, sebuah organisasi mungkin memilih untuk memberikan kelonggaran USDC tak terbatas pada router DEX untuk kenyamanan operasional, yang kemudian memaparkan mereka pada risiko jika kontrak router ditingkatkan.

1.4 Antarmuka web yang disusupi

Sebagian besar pengguna tidak berinteraksi langsung dengan kontrak pintar, melainkan melalui antarmuka web melalui perangkat seluler atau browser web mereka.

Frontend ini dapat rentan terhadap serangan melalui cara yang sudah dikenal seperti pembajakan DNS, injeksi javascript berbahaya, hosting yang tidak aman, atau berbagai dependensi pihak ketiga. UX aplikasi yang disusupi dapat mengarahkan semua jenis pengguna ke kontrak pintar berbahaya atau mengarahkan mereka untuk menandatangani transaksi yang menyesatkan.

1.5 Privasi

Privasi dapat memitigasi atau memperbesar risiko keamanan bagi semua jenis pengguna.

Perlindungan privasi yang lebih lemah memaparkan pengguna individu pada berbagai ancaman yang ditargetkan seperti phishing, eksploitasi, penipuan, atau serangan fisik. Banyak pola UX umum yang memaparkan pengguna, misalnya, penggunaan kembali alamat, data KYC, dan kebocoran metadata lainnya.

Bagi institusi dan perusahaan, privasi sering kali merupakan persyaratan bisnis mendasar untuk alasan kepatuhan atau kasus penggunaan tertentu. Selain masalah tersebut, hal ini dapat menciptakan paparan terhadap risiko keamanan tertentu. Misalnya, pengguna sistem rantai pasokan yang dibangun di Ethereum mungkin memerlukan jaminan privasi yang kuat untuk melindungi aset kekayaan intelektual yang dapat disusupi jika sistem tersebut transparan.

1.6 Fragmentasi

Terdapat ketidakkonsistenan dalam cara berbagai dompet menangani perilaku inti seperti menampilkan transaksi, menangani persetujuan, atau melabeli kontrak. Fragmentasi pengalaman pengguna ini menambah hambatan pada kemampuan pengguna untuk mempelajari cara menggunakan dompet dengan aman, dan meningkatkan risiko.

Misalnya, pengguna tidak dapat mengandalkan isyarat UX yang konsisten untuk melindungi diri mereka dari phishing dan spoofing karena berbeda di seluruh dompet. Pengguna tidak dapat membentuk ekspektasi yang dapat diandalkan tentang cara kerja Ethereum jika setiap alat berfungsi secara berbeda.

Keamanan kontrak pintar telah meningkat secara radikal sepanjang sejarah Ethereum. Insiden keamanan awal seperti peretasan DAO memotivasi ekosistem untuk memprofesionalkan dan meningkatkan perlindungan di seluruh siklus hidup perangkat lunak yang mengarah pada kode yang diterapkan onchain. Kemajuan utama meliputi:

• Audit keamanan menjadi praktik standar, dengan beberapa firma keamanan memasuki ekosistem dan mengembangkan keahlian.
• Peralatan, pengujian, dan sistem analisis statis menjadi matang dan menjadi praktik standar.
• Pustaka komponen umum yang telah diaudit sebelumnya memberi pengembang blok bangunan yang aman secara default.
• Teknik verifikasi formal diadopsi, terutama untuk jembatan, sistem mengunci, dan kontrak bernilai tinggi.
• Budaya keamanan dan praktik terbaik ekosistem meningkat.
• Penciptaan program bounty yang signifikan yang memperkuat lapisan aplikasi.

Namun, masih ada kelemahan dan area untuk peningkatan dalam domain ini.

2.1 Kerentanan kontrak

Meskipun ada kemajuan dalam keamanan kontrak pintar, masih ada kerentanan yang dapat menyebabkan masalah keamanan yang signifikan, termasuk:

• Risiko peningkatan kontrak. Beberapa kontrak dirancang untuk dapat dimodifikasi setelah penerapan, untuk memungkinkan tim pengembangan terus memperbarui dan meningkatkan aplikasi. Namun, ini memperkenalkan risiko. Peningkatan dapat mengakibatkan kerentanan baru, atau hilangnya total dana pengguna jika terjadi peningkatan yang berbahaya.
• Re-entrancy, di mana kontrak A memanggil kontrak eksternal B sebelum memperbarui status internalnya sendiri, dan kontrak B memanggil kembali ke kontrak asli A sebelum panggilan pertama selesai.
• Penggunaan pustaka eksternal yang tidak aman, di mana kontrak memanggil pustaka eksternal yang mungkin tidak diaudit, berbahaya, atau dapat ditingkatkan.
• Komponen yang tidak diaudit. Meskipun audit dan penggunaan pustaka standar telah meningkat, pengembang terkadang mengandalkan komponen yang tidak diaudit dalam aplikasi mereka.
• Kegagalan kontrol akses, di mana izin salah dikonfigurasi atau didefinisikan terlalu luas, memungkinkan penyerang untuk mengambil tindakan berbahaya.
• Akses Tidak Sah, di mana kunci pribadi yang mampu mengontrol kontrak diperoleh oleh aktor jahat.
• Jembatan dan interaksi lintas chain. Jembatan dan protokol lintas chain memperkenalkan kompleksitas tambahan, dan penyerang dapat mengeksploitasi kelemahan dalam cara pesan lintas chain diteruskan atau divalidasi.
• Delegasi akun yang dimiliki secara eksternal (EOA) atau penyalahgunaan tanda tangan. Aplikasi berbahaya dapat menipu pengguna agar menandatangani delegasi penuh akun mereka ke pihak lain, yang memungkinkan pencurian. Aplikasi berbahaya juga dapat menggunakan pesan yang ditandatangani dari pengguna dengan cara yang tidak terduga, misalnya, dalam serangan replay.
• Risiko bug yang muncul yang diperkenalkan oleh pembuatan kode AI atau alat refactoring otomatis.

2.2 Pengalaman pengembang, peralatan, dan bahasa pemrograman

Kerentanan berakhir pada kode yang diterapkan sebagai akibat dari kesalahan pengembang. Peralatan pengembang yang ditingkatkan telah membuatnya jauh lebih mudah untuk menerapkan kontrak pintar yang aman. Namun, masalah tetap ada.

• Kurangnya default yang aman dalam kerangka kerja populer. Beberapa alat memprioritaskan fleksibilitas atau kecepatan di atas keamanan, menetapkan default yang tidak aman seperti persetujuan token tak terbatas dalam fungsi approve(), atau gagal menyertakan pola kontrol akses secara default.
• Kode khusus untuk kontrol operasional tingkat lanjut. Pengguna institusional dengan persyaratan operasional yang kompleks sering kali harus membangun fitur yang diperlukan dari awal, meningkatkan risiko kerentanan. Terdapat kekurangan komponen atau kerangka kerja aman yang terstandarisasi untuk alur kerja keamanan tingkat lanjut.
• Cakupan pengujian yang tidak konsisten di seluruh tumpukan peralatan, serta kurangnya norma seputar penggunaan teknik yang terbukti seperti fuzzing atau pemeriksaan invarian.
• Rendahnya adopsi metode verifikasi formal. Teknik verifikasi formal sangat kuat, tetapi kompleks, mahal, memerlukan keahlian domain khusus, dan tidak terintegrasi dengan baik ke dalam alur kerja pengembang standar, di mana teknik tersebut dapat digunakan jauh lebih awal dalam produksi perangkat lunak untuk memverifikasi keamanan pada tahap spesifikasi.
• Masalah terkait verifikasi kontrak. Pengguna dan pengembang tidak dapat dengan mudah menilai kepercayaan kontrak yang diterapkan, sejauh mana validasi keamanan mereka (misalnya, audit kode), atau adanya risiko laten. Meskipun ada solusi untuk tujuan ini, banyak masalah tetap ada. Peralatan yang mengatasi masalah ini tidak diadopsi secara luas, standar yang akan menyatukan pendekatan tetap terfragmentasi, dan beberapa layanan yang ada itu sendiri merupakan dependensi terpusat.
• Risiko kompiler. Kompiler (perangkat lunak yang mengubah kode yang dapat dibaca manusia seperti Solidity menjadi bytecode yang digunakan oleh EVM itu sendiri) dapat memiliki kelemahan yang memasukkan kesalahan ke dalam kontrak pintar sebelum diterapkan. Ekosistem Ethereum saat ini sebagian besar bergantung pada kompiler solc, yang berarti bug dapat memiliki efek yang meluas.
• Keragaman dan kedalaman bahasa pemrograman. Meskipun Solidity memiliki ekosistem peralatan yang dalam yang dibangun di atasnya, beberapa pengembang menginginkan fitur keamanan yang lebih modern yang ditemukan dalam bahasa pemrograman lain, seperti keamanan memori.

2.3 Penilaian risiko kode onchain

Institusi dan perusahaan memiliki proses, standar, dan persyaratan yang ada untuk mengevaluasi keamanan teknologi dan sistem yang mereka andalkan. Namun, kerangka kerja yang ada sering kali tidak memetakan dengan rapi ke kontrak pintar, biasanya mengasumsikan kode yang dapat diubah, kontrol perubahan terpusat, dan garis akuntabilitas atau kewajiban hukum yang jelas. Sistem yang dibangun di atas kontrak pintar terkadang dapat melanggar asumsi tersebut, sehingga menyulitkan organisasi untuk mengadopsi Ethereum dan mengelola risiko dengan tepat.

Sistem ini merupakan permukaan serangan baik untuk dompet dan lapisan aplikasi (misalnya, titik akhir RPC untuk dompet) maupun untuk protokol Ethereum itu sendiri (misalnya, banyak validator di-host pada infrastruktur cloud). Kompromi kunci pribadi, phishing, dan kurangnya kontrol akses granular dapat menyebabkan pemadaman skala besar, pencurian, atau perubahan yang tidak sah, bahkan jika protokol blockchain yang mendasarinya tetap aman.

3.1 Chain layer 2

Chain layer 2 (L2) berfungsi sebagai ekstensi untuk Ethereum, memungkinkan lingkungan yang lebih cepat dan biaya lebih rendah sambil mempertahankan beberapa karakteristik jaminan keamanan mainnet Ethereum (tergantung pada desain spesifiknya). Namun, mereka juga memiliki permukaan serangan yang berbeda termasuk:

• Kompleksitas aset yang dijembatani multi-hop. Ketika aset berpindah antara L1 dan beberapa L2, aset tersebut terpapar pada beberapa set kontrak yang semuanya harus aman. Akuntansi yang tidak cocok atau pemadaman di chain L2 dapat memperkenalkan kerentanan yang dapat dieksploitasi oleh penyerang.
• L2 rollup mengandalkan sistem pembuktian untuk menegakkan kebenaran pembaruan status. Bug atau kesalahan konfigurasi dalam sistem ini dapat menghentikan atau mencegah finalisasi, atau memungkinkan finalisasi pembaruan status palsu yang menyebabkan hilangnya dana pengguna.
• Dewan keamanan adalah kelompok pemegang kunci yang berfungsi sebagai mekanisme "cadangan" untuk meningkatkan perangkat lunak L2 atau merespons keadaan darurat tertentu. Dewan keamanan itu sendiri menimbulkan risiko, karena kompromi atau kolusi di antara anggota dapat membahayakan dana pengguna atau membekukan aset.

Lihat L2Beat (opens in a new tab) untuk kerangka kerja terperinci dan dasbor pemantauan yang mengevaluasi dan membandingkan kinerja dan keamanan L2.

3.2 Infrastruktur RPC dan node

Aplikasi Ethereum bergantung pada sejumlah kecil penyedia infrastruktur untuk akses RPC, API, dan layanan node. Ini termasuk penyedia infrastruktur khusus kripto, serta layanan cloud tradisional yang biasa digunakan untuk meng-host node (misalnya, AWS, Cloudflare, Hetzner).

Jika penyedia infrastruktur ini offline atau mencoba menyensor atau membatasi akses, banyak pengguna dapat dicegah untuk mengakses Ethereum melalui dompet atau aplikasi mereka, sampai mereka dapat bermigrasi ke RPC baru atau penyedia infrastruktur lainnya. Beberapa penyedia ini sebelumnya telah menangguhkan atau menutup akun yang terkait dengan aktivitas blockchain, meningkatkan kekhawatiran tentang keandalan jangka panjang mereka untuk aplikasi terdesentralisasi.

3.3 Kerentanan tingkat DNS

Sistem Nama Domain (DNS) adalah lapisan dasar internet, tetapi juga terpusat dan dapat disusupi. Banyak pengguna mengakses aplikasi melalui domain web, yang rentan terhadap:

• Pembajakan DNS di mana penyerang menyisipkan frontend palsu yang berbahaya.
• Penyitaan domain, di mana pemerintah atau pendaftar dapat menyita domain.
• Phishing melalui domain mirip, di mana penyerang mendaftarkan nama yang hampir identik untuk membingungkan pengguna.

3.4 Rantai pasokan perangkat lunak dan pustaka

Pengembang Ethereum mengandalkan pustaka sumber terbuka, sering kali ditarik langsung dari layanan seperti npm, crates.io, atau GitHub. Jika pustaka ini disusupi, mereka dapat menjadi vektor untuk serangan seperti:

• Injeksi paket berbahaya, di mana penyerang menyusupi paket yang banyak digunakan atau menerbitkannya dengan nama yang mirip
• Dependensi yang dibajak, di mana pengelola kehilangan kendali atas proyek dan aktor jahat memasukkan kode berbahaya
• Kompromi pengembang, di mana paket yang diinstal berisi kode yang memberi penyerang kendali atas komputer pengembang.

3.5 Layanan pengiriman frontend dan risiko terkait

Banyak aplikasi Ethereum menyajikan frontend mereka melalui Jaringan Pengiriman Konten (CDN) atau platform hosting berbasis cloud (misalnya, Vercel, Netlify, Cloudflare). Jika layanan ini disusupi, mereka dapat menjadi vektor untuk serangan seperti injeksi javascript berbahaya, di mana penyerang menyajikan frontend yang diubah kepada pengguna.

3.6 Penyensoran tingkat Penyedia Layanan Internet

Penyedia Layanan Internet (ISP) atau negara bangsa dapat menggunakan kendali atas infrastruktur internet yang mendasarinya untuk menyensor akses ke Ethereum. Misalnya, serangan ini dapat mencakup:

• Memblokir atau membatasi lalu lintas ke port Ethereum umum
• Memfilter permintaan DNS yang mengarah ke layanan terkait Ethereum
• Geofencing atau larangan IP terhadap node Ethereum yang diketahui
• Inspeksi paket mendalam untuk mengidentifikasi dan menyensor lalu lintas terkait protokol Ethereum

Banyak dari teknik dasar ini sudah digunakan oleh pemerintah otoriter di seluruh dunia untuk menekan akses ke informasi, alat protes, atau mata uang kripto saat ini.

Protokol konsensus Ethereum telah terbukti kuat dalam praktiknya, dengan nol waktu henti sejak pertama kali diluncurkan pada tahun 2015 dan di beberapa peningkatan. Namun, masih ada area jangka panjang untuk peningkatan guna membuat sistem lebih tangguh dan aman.

4.1 Kerapuhan konsensus dan risiko pemulihan

Pilihan fork dan aturan finalitas Ethereum tangguh, tetapi tidak kebal. Selama kondisi kasus tepi tertentu (seperti ketidaksepakatan validator yang berkepanjangan, bug klien, atau partisi jaringan) konsensus dapat terhenti atau menyimpang sementara. Dalam kondisi ekstrem, hal ini dapat menyebabkan penalti validator yang berjenjang melalui kebocoran ketidakaktifan atau pemotongan, yang selanjutnya dapat menyebabkan pelarian modal dari validator.

4.2 Keragaman klien

Keragaman klien Ethereum yang terdepan di industri melindungi jaringan dari bug di klien mana pun. Namun, keragaman klien masih dapat ditingkatkan dengan lebih banyak adopsi klien minoritas untuk mengurangi risiko ini lebih jauh.

4.3 Sentralisasi mengunci dan dominasi kolam

Sejumlah besar bobot validator terkonsentrasi dalam protokol liquid staking, layanan kustodian, dan operator node besar. Konsentrasi ini dapat menyebabkan risiko seperti:

• Penangkapan atau pengaruh tata kelola. Jika entitas yang mengendalikan sejumlah besar stake (atau entitas dengan kekuatan hukum untuk memengaruhi entitas tersebut) berkoordinasi bersama, mereka dapat memiliki pengaruh yang sangat besar pada blok mana yang diusulkan dan dibuktikan, berpotensi menyensor pengguna, atau memengaruhi peningkatan protokol.
• Homogenitas dalam pilihan klien dan pengaturan infrastruktur, yang dapat meningkatkan risiko kegagalan yang berkorelasi.

4.4 Pemotongan sosial yang tidak terdefinisi dan kesenjangan koordinasi

Dalam beberapa mode kegagalan ekstrem, Ethereum akan mengandalkan "pemotongan sosial" untuk menghukum validator yang bertindak jahat untuk menyerang jaringan (lihat bagian 6.1). Namun, infrastruktur, norma, dan proses yang diharapkan untuk jenis pemotongan ini kurang berkembang. Tidak ada mekanisme mapan yang akan digunakan komunitas untuk terlibat dalam proses ini.

4.5 Vektor serangan ekonomi dan teori permainan

Banyak potensi vektor serangan ekonomi masih kurang dipelajari, termasuk:

• Serangan griefing atau slash griefing. Validator dapat menanggung biaya atau penalti pemotongan bukan karena kesalahan mereka sendiri tetapi karena perilaku permusuhan yang dimaksudkan semata-mata untuk merugikan orang lain dengan biaya bersih bagi penyerang.
• Keluar strategis atau ketidakaktifan berwaktu. Validator dapat dengan sengaja offline atau keluar pada saat-saat kritis untuk memaksimalkan keuntungan atau mengganggu konsensus dengan penalti minimal.
• Kolusi di antara validator atau relai. Perilaku terkoordinasi antara validator atau antara relai dan validator dapat mengurangi desentralisasi, atau mengekstraksi nilai ekstraksi maksimum.
• Eksploitasi insentif kasus tepi dalam nilai ekstraksi maksimum, pemisahan pengusul-pembangun, atau desain liquid staking. Aktor dapat memanipulasi kondisi protokol yang langka untuk mendapatkan hadiah yang sangat besar.

4.6 Risiko kuantum

Kriptografi inti Ethereum (misalnya, tanda tangan kurva eliptik seperti secp256k1) suatu hari nanti dapat dipatahkan oleh komputer kuantum. Meskipun ini bukan risiko yang akan segera terjadi, ancaman yang kredibel dapat secara instan membuat dompet, kontrak, dan kunci mengunci yang ada menjadi rentan. Tantangan masa depan ini melemahkan jaminan jangka panjang Ethereum kepada pengguna.

Jalur migrasi ke kriptografi tahan kuantum (misalnya, melalui skema tanda tangan pasca-kuantum) perlu dirancang, diuji, dan mungkin disematkan dalam protokol bertahun-tahun sebelum dibutuhkan. Organisasi di seluruh ekosistem Ethereum, termasuk Ethereum Foundation, secara aktif mengeksplorasi opsi ini dan memantau risiko.

Bahkan ekosistem blockchain yang diidealkan akan memiliki risiko, serangan, dan kerentanan. Ketika terjadi kesalahan, harus ada sistem yang efektif untuk memitigasi, mendeteksi, dan merespons. Tantangan di sini meliputi:

• Menjangkau tim yang terkena dampak. Mungkin sulit untuk menghubungi tim yang aplikasinya telah disusupi. Hal ini dapat menyebabkan penundaan berjam-jam, membatasi kemampuan responden untuk memulihkan dana.
• Meningkatkan masalah di organisasi terkait. Ketika masalah melibatkan platform (seperti jejaring sosial atau bursa terpusat), mungkin menantang bagi responden untuk meningkatkan masalah jika mereka tidak memiliki kontak yang sudah ada sebelumnya.
• Koordinasi respons. Sering kali tidak jelas berapa banyak tim respons insiden yang membantu aplikasi yang terkena dampak, yang menyebabkan miskomunikasi atau upaya yang sia-sia ketika upaya kelompok mungkin lebih efektif.
• Kurangnya kemampuan pemantauan. Mungkin sulit untuk memantau masalah onchain dan offchain, yang akan memberikan peringatan dini dan memastikan respons cepat terhadap ancaman.
• Akses ke asuransi. Asuransi adalah alat penting untuk memitigasi kerugian di sebagian besar sistem tradisional yang berurusan dengan uang, sistem keuangan, identitas, dan informasi berharga lainnya. Namun, saat ini hanya sedikit opsi asuransi yang tersedia dari layanan keuangan tradisional untuk ekosistem kripto.

Risiko ini cenderung lebih berorientasi jangka panjang, dan menyangkut Ethereum secara keseluruhan daripada keamanan pengguna atau aplikasi individu.

6.1 Sentralisasi stake

Sentralisasi sejumlah besar stake dapat menimbulkan risiko bagi Ethereum secara keseluruhan jika entitas yang mengendalikan stake tersebut memutuskan untuk berkolusi.
Sentralisasi ekonomi ini menciptakan potensi penangkapan tata kelola sosial. Jika sekelompok kecil validator mengendalikan mayoritas super stake, mereka dapat:

• Berkoordinasi pada atau menolak fork.
• Menyensor transaksi atau kontrak tertentu.
• Merusak konsensus komunitas dengan mengancam keluar atau oposisi.

Jika skenario ekstrem ini terjadi, komunitas Ethereum telah menyarankan bahwa "pemotongan sosial" mungkin menjadi jawabannya. Pemotongan sosial adalah penggunaan konsensus sosial offchain untuk memutuskan memotong validator yang berperilaku buruk, sebagai pemeriksaan atas kekuasaan mereka. Namun, tidak ada norma, prosedur, atau peralatan yang jelas untuk memberlakukan tindakan tersebut (lihat bagian 4.4).

6.2 Sentralisasi aset offchain

Ethereum menampung sejumlah besar aset dunia nyata, di mana aset tersebut disimpan offchain di rekening bank atau deposito lainnya, yang kemudian diperdagangkan onchain melalui token yang mewakili klaim atas aset offchain. Misalnya, banyak stablecoin besar berfungsi dengan cara ini.

Institusi yang memegang deposito offchain mungkin memiliki pengaruh atas ekosistem Ethereum. Misalnya, selama skenario ekstrem di mana terdapat fork atau peningkatan jaringan yang kontroversial, deposan besar dapat memengaruhi chain mana yang diterima secara luas dengan hanya memilih untuk mengenali token pada satu chain atau yang lain.

6.3 Serangan atau tekanan regulasi

Pemerintah dan regulator dapat menekan berbagai entitas yang mengendalikan komponen penting dari tumpukan Ethereum untuk menyensor atau mengganggu protokol Ethereum. Pengguna institusional Ethereum juga dapat terkena dampak dari tekanan ini, yang akan memiliki konsekuensi lebih lanjut bagi pengguna mereka (misalnya, bank yang tidak dapat lagi menawarkan produk kripto tertentu karena larangan regulasi).

6.4 Penangkapan tata kelola organisasi

Tata kelola sumber terbuka dan proses pengembangan Ethereum didorong oleh serangkaian tim dan perusahaan yang beragam dan global yang memelihara perangkat lunak klien inti, infrastruktur, dan peralatan.

Berbagai bentuk pengaruh (akuisisi perusahaan, ketergantungan pendanaan, mempekerjakan kontributor utama, konflik kepentingan di dalam organisasi yang ada) dapat secara bertahap menggeser budaya dan prioritas tata kelola Ethereum. Hal ini dapat mengarah pada penyelarasan dengan kepentingan komersial atau eksternal tertentu yang menyimpang dari etos yang didorong oleh komunitas dan peta jalan yang mapan, yang berpotensi melemahkan netralitas dan ketahanan Ethereum dari waktu ke waktu.