Tinjauan Tantangan Keamanan

Salah satu fitur penentu dari rantai blok adalah sifat atomik dari transaksi: setelah pembaruan dicatat ke dalam rantai blok, 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 secara aman, berinteraksi dengan aplikasi onchain, dan menggunakan kunci mereka untuk menandatangani transaksi untuk mentransfer aset atau memperbarui state Ethereum.

Masing-masing persyaratan ini memperkenalkan risiko seperti kompromi atau kehilangan kunci, persetujuan yang terburu-buru atau tanpa informasi, atau kompromi perangkat lunak dompet yang diandalkan pengguna untuk menginformasikan dan memandu mereka dalam berinteraksi 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 untuk menyimpan frasa benih (seed phrase) dengan aman yang mewakili kunci privat kriptografi yang mendasarinya, yang sering kali mengarahkan mereka untuk menggunakan solusi yang tidak aman seperti menyimpan frasa benih 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 di 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 dimaklumi merasa gugup tentang hak asuh mandiri (self custody) ketika itu dapat disusupi melalui pencurian fisik atau penyerangan.

Pengguna perusahaan dan institusi menghadapi tantangan tambahan dalam manajemen kunci. Jika karyawan individu memegang kunci (misalnya, sebagai bagian dari dompet multisig), 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 kustom 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 bursa 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 diselesaikan 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 tersebut dapat menguras dana pengguna.

Ini juga merupakan risiko bagi pengguna organisasi. Misalnya, sebuah organisasi mungkin memilih untuk memberikan jatah USDC tak terbatas kepada 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 via perangkat seluler atau peramban web mereka.

Frontend ini bisa rentan terhadap serangan melalui cara-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 mengekspos pengguna, misalnya, penggunaan kembali alamat, data KYC, dan kebocoran metadata lainnya.

Bagi institusi dan perusahaan, privasi sering kali menjadi 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 kurangnya konsistensi 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 isyarat tersebut berbeda di setiap 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 disebarkan onchain. Kemajuan utama meliputi:

• Audit keamanan menjadi praktik standar, dengan beberapa firma keamanan memasuki ekosistem dan mengembangkan keahlian.
• Alat, 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 staking, 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 perbaikan 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 agar dapat dimodifikasi setelah penyebaran, untuk memungkinkan tim pengembangan terus memperbarui dan meningkatkan aplikasi. Namun, hal 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 state 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 privat yang mampu mengontrol kontrak diperoleh oleh aktor jahat.
• Jembatan dan interaksi lintas rantai. Jembatan dan protokol lintas rantai memperkenalkan kompleksitas tambahan, dan penyerang dapat mengeksploitasi kelemahan dalam cara pesan lintas rantai diteruskan atau divalidasi.
• Penyalahgunaan pendelegasian atau tanda tangan Externally Owned Account (EOA). Aplikasi berbahaya dapat menipu pengguna agar menandatangani pendelegasian penuh atas 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, alat, dan bahasa pemrograman

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

• Kurangnya default yang aman dalam kerangka kerja populer. Beberapa alat memprioritaskan fleksibilitas atau kecepatan daripada keamanan, menetapkan default yang tidak aman seperti persetujuan token tak terbatas dalam fungsi approve(), atau gagal menyertakan pola kontrol akses secara default.
• Kode kustom 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 alat, 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 disebarkan, sejauh mana validasi keamanan mereka (misalnya, audit kode), atau adanya risiko laten. Meskipun ada solusi untuk tujuan ini, banyak masalah tetap ada. Alat 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 kode bita yang digunakan oleh EVM itu sendiri) dapat memiliki kelemahan yang memasukkan kesalahan ke dalam kontrak pintar sebelum disebarkan. Ekosistem Ethereum saat ini sebagian besar bergantung pada kompiler solc, yang berarti sebuah bug dapat memiliki efek yang meluas.
• Keragaman dan kedalaman bahasa pemrograman. Meskipun Solidity memiliki ekosistem perkakas yang mendalam 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 dapat dipetakan dengan rapi ke dalam 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 mematahkan asumsi tersebut, sehingga menyulitkan organisasi untuk mengadopsi Ethereum dan mengelola risiko dengan tepat.

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

3.1 Rantai lapisan 2 (l2)

Rantai lapisan 2 (l2) berfungsi sebagai ekstensi untuk Ethereum, memungkinkan lingkungan yang lebih cepat dan berbiaya lebih rendah sambil mempertahankan beberapa jaminan keamanan karakteristik dari Mainnet Ethereum (tergantung pada desain spesifiknya). Namun, mereka juga memiliki permukaan serangan tersendiri termasuk:

• Kompleksitas aset yang dijembatani multi-hop. Ketika aset berpindah antara lapisan 1 (l1) dan beberapa l2, aset tersebut terpapar pada beberapa set kontrak yang semuanya harus aman. Ketidaksesuaian akuntansi atau pemadaman pada rantai l2 dapat memunculkan kerentanan yang dapat dieksploitasi oleh penyerang.
• Rollup l2 bergantung pada sistem pembuktian untuk menegakkan kebenaran pembaruan state. Bug atau kesalahan konfigurasi dalam sistem ini dapat menghentikan atau mencegah finalisasi, atau memungkinkan finalisasi pembaruan state yang salah yang mengarah pada 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 serta 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 umumnya digunakan untuk menghosting node (misalnya, AWS, Cloudflare, Hetzner).

Jika penyedia infrastruktur ini luring 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 rantai blok, sehingga menimbulkan 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 dikompromikan. 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 tiruan, 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, yang sering kali ditarik langsung dari layanan seperti npm, crates.io, atau GitHub. Jika pustaka ini dikompromikan, mereka dapat menjadi vektor untuk serangan seperti:

• Injeksi paket berbahaya, di mana penyerang mengompromikan paket yang banyak digunakan atau menerbitkan paket dengan nama yang mirip
• Dependensi yang dibajak, di mana pengelola kehilangan kendali atas suatu 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 dikompromikan, mereka dapat menjadi vektor untuk serangan seperti injeksi JavaScript berbahaya, di mana penyerang menyajikan frontend yang diubah kepada pengguna.

3.6 Sensor 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 yang umum
• Menyaring permintaan DNS yang mengarah ke layanan terkait Ethereum
• Pembatasan wilayah (geofencing) atau pemblokiran IP terhadap node Ethereum yang diketahui
• Inspeksi paket mendalam untuk mengidentifikasi dan menyensor lalu lintas terkait protokol Ethereum

Banyak dari teknik dasar ini telah 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 tangguh dalam praktiknya, dengan nol waktu henti sejak pertama kali diluncurkan pada tahun 2015 dan di berbagai peningkatan. Namun, masih ada area jangka panjang untuk perbaikan guna membuat sistem lebih tangguh dan aman.

4.1 Kerapuhan konsensus dan risiko pemulihan

Aturan pilihan percabangan dan finalitas Ethereum memang tangguh, tetapi tidak kebal. Selama kondisi kasus ekstrem tertentu (seperti ketidaksepakatan validator yang berkepanjangan, bug klien, atau partisi jaringan), konsensus dapat terhenti atau menyimpang untuk sementara. Dalam kondisi ekstrem, hal ini dapat menyebabkan penalti validator yang beruntun 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 pada klien tunggal mana pun. Namun, keragaman klien masih dapat ditingkatkan dengan lebih banyak adopsi klien minoritas untuk mengurangi risiko ini lebih jauh.

4.3 Sentralisasi staking dan dominasi pool

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

• Pengambilalihan 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 terhadap 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 bergantung pada "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 yang masih kurang dipelajari, termasuk:

• Serangan griefing atau griefing pemotongan. Validator dapat menanggung biaya atau penalti pemotongan bukan karena kesalahan mereka sendiri tetapi karena perilaku musuh yang semata-mata ditujukan untuk merugikan orang lain dengan biaya bersih bagi penyerang.
• Keluar secara strategis atau ketidakaktifan yang diatur waktunya. Validator dapat dengan sengaja luring 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 MEV.
• Eksploitasi insentif kasus ekstrem dalam MEV, pemisahan pengusul-pembangun (PBS), atau desain staking likuid. Aktor dapat memanipulasi kondisi protokol yang langka untuk mendapatkan imbalan yang sangat besar.

4.6 Risiko kuantum

Kriptografi inti Ethereum (misalnya, tanda tangan kurva eliptik seperti secp256k1) suatu hari nanti dapat dipecahkan oleh komputer kuantum. Meskipun ini bukan risiko yang akan segera terjadi, ancaman yang kredibel dapat secara instan membuat dompet, kontrak, dan kunci staking 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 Yayasan Ethereum, secara aktif mengeksplorasi opsi-opsi ini dan memantau risiko.

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

• Menghubungi tim yang terdampak. Bisa jadi sulit untuk menghubungi tim yang aplikasinya telah dikompromikan. 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), bisa menjadi tantangan 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 terdampak, yang mengarah pada miskomunikasi atau upaya yang sia-sia ketika upaya kelompok mungkin lebih efektif.
• Kurangnya kemampuan pemantauan. Bisa jadi 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-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 pengambilalihan tata kelola sosial. Jika sekelompok kecil validator mengendalikan mayoritas super stake, mereka dapat:

• Berkoordinasi pada atau menolak percabangan.
• Menyensor transaksi atau kontrak tertentu.
• Merusak konsensus komunitas dengan mengancam untuk keluar atau melakukan penentangan.

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 perkakas yang jelas untuk memberlakukan tindakan tersebut (lihat bagian 4.4).

6.2 Sentralisasi aset offchain

Ethereum menampung sejumlah besar aset dunia nyata (RWA), di mana aset tersebut disimpan secara offchain di rekening bank atau deposito lainnya, yang kemudian diperdagangkan secara onchain melalui token yang mewakili klaim atas aset offchain tersebut. 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 percabangan atau peningkatan jaringan yang kontroversial, deposan besar dapat memengaruhi rantai mana yang diterima secara luas dengan hanya memilih untuk mengakui token pada satu rantai atau rantai lainnya.

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 Pengambilalihan tata kelola oleh 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 perkakas.

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