Tổng quan về các thách thức bảo mật

Một đặc điểm xác định của các blockchain là tính chất nguyên tử của các giao dịch: một khi một bản cập nhật được ghi lại vào blockchain, sẽ không có cơ hội can thiệp hoặc đảo ngược. Điều này cung cấp những đảm bảo mạnh mẽ về tính nhất quán và an ninh ở cấp độ giao thức, nhưng cũng khiến người dùng phải đối mặt với rủi ro hoạt động gia tăng: một sai lầm đơn lẻ, khóa bị xâm phạm hoặc sự phê duyệt vội vàng có thể dẫn đến tổn thất không thể đảo ngược.

Do đó, một gánh nặng đáng kể về an ninh thuộc về người dùng. Để sử dụng Ethereum một cách an toàn, cá nhân và tổ chức phải giữ và quản lý khóa một cách an toàn, tương tác với các ứng dụng trên chuỗi, và sử dụng khóa của họ để ký các giao dịch nhằm chuyển nhượng tài sản hoặc cập nhật trạng thái của Ethereum.

Mỗi yêu cầu này đều đưa ra những rủi ro như việc bị xâm phạm khóa bí mật hoặc mất mát, sự phê duyệt vội vàng hoặc thiếu thông tin, hoặc sự xâm phạm phần mềm ví mà người dùng dựa vào để thông báo và hướng dẫn họ trong việc tương tác với Ethereum.

1,1 Quản lý khóa

Nhiều người dùng không được trang bị để quản lý các khóa mật mã một cách an toàn.

Phần mềm ví điện tử được sử dụng rộng rãi nhất phụ thuộc vào việc người dùng lưu trữ một cách an toàn các cụm từ khôi phục đại diện cho khóa riêng mật mã cơ bản của họ, điều này thường dẫn đến việc họ sử dụng các cách làm không an toàn như lưu trữ các cụm từ khôi phục dưới dạng văn bản thuần, trên các dịch vụ đám mây, hoặc ghi chúng ra giấy.

Ví phần cứng là một sự lựa chọn thay thế, cho phép người dùng quản lý một khóa mã hóa được lưu trữ trong một thiết bị vật lý có mục đích đặc biệt. Tuy nhiên, ví phần cứng cũng có những thiếu sót và bề mặt tấn công riêng. Ví phần cứng có thể bị mất, hư hỏng hoặc bị đánh cắp. Nhiều ví phần cứng không phải là mã nguồn mở và có thể có chuỗi cung ứng không minh bạch, làm tăng rủi ro của một cuộc tấn công vào chuỗi cung ứng, trong đó các thiết bị bị xâm phạm được bán ra thị trường.

Dù chìa khóa được quản lý trong ví phần mềm hay ví phần cứng, nhiều người dùng có lý do chính đáng để lo lắng về việc quản lý tài sản của mình, khi nó có thể bị xâm phạm qua trộm cắp vật lý hoặc hành hung.

Người dùng doanh nghiệp và tổ chức phải đối mặt với những thách thức bổ sung trong việc quản lý khóa. Nếu các nhân viên cá nhân nắm giữ khóa (ví dụ: là một phần của ví đa chữ ký), tổ chức phải có khả năng thay thế chúng và tạo ra các khóa mới do sự thay đổi nhân sự theo thời gian. Các yêu cầu tuân thủ trong các ngành công nghiệp và khu vực pháp lý khác nhau có thể đòi hỏi các quy trình làm việc tùy chỉnh hoặc dấu vết kiểm toán mà phần mềm ví hiện tại không hỗ trợ. Trong một số trường hợp, người dùng doanh nghiệp chuyển sang các tổ chức bên thứ ba để quản lý tài sản kỹ thuật số, một điều có thể làm gia tăng thêm một lớp rủi ro bảo mật cần được xem xét.

1.2 Ký mù và sự không chắc chắn trong giao dịch

Người dùng thường phê duyệt các giao dịch một cách "mù quáng" mà không hiểu họ đang làm gì. Ví thường trình bày dữ liệu thô ở dạng hệ thập phân hệ số 16, địa chỉ hợp đồng bị cắt ngắn, hoặc các thông tin khác không đủ để người dùng hiểu được hậu quả của một giao dịch cụ thể. Điều này khiến cho người dùng thuộc mọi loại hình dễ bị tổn thương trước các hợp đồng thông minh độc hại, lừa đảo qua mạng, gian lận, giao diện giả danh, sự xâm phạm giao diện người dùng phía trước, và các lỗi cơ bản của người dùng.

1.3 Quản lý phê duyệt và cấp phép

Trong nhiều ứng dụng Ethereum, việc người dùng cấp quyền nhất định cho ứng dụng cơ sở là điều thường thấy trong quá trình sử dụng bình thường. Ví dụ, người dùng có thể cấp quyền cho một sàn giao dịch phi tập trung như Uniswap để di chuyển các token của họ nhằm mục đích hoán đổi chúng lấy ETH.

Những phê duyệt này có thể có giới hạn về số lượng, nhưng nhiều ví mặc định cho phép cấp phê duyệt không giới hạn mà không có ngày hết hạn. Không có cách nào cho người dùng quản lý hoặc xem xét các phê duyệt còn lại từ hầu hết các ví.

Điều này có thể khiến người dùng phải đối mặt với các ứng dụng ác ý hoặc các giao diện bị xâm phạm, bởi vì mẫu mặc định cho nhiều người dùng là cấp quyền không giới hạn, điều này có thể bị lợi dụng để rút tiền của họ. Ngay cả khi một người dùng cấp quyền cho một hợp đồng thông minh hợp pháp, nếu hợp đồng đó sau này bị xâm phạm trong khi quyền cấp vẫn còn hiệu lực, thì hợp đồng bị xâm phạm đó có thể rút cạn tài sản của người dùng.

Điều này cũng là một nguy cơ đối với người dùng trong tổ chức. Chẳng hạn, một tổ chức có thể quyết định cấp quyền sử dụng USDC không giới hạn cho một bộ định tuyến DEX để thuận tiện trong hoạt động, điều này sẽ khiến họ phải đối mặt với rủi ro nếu hợp đồng của bộ định tuyến được nâng cấp.

1.4 Giao diện web bị xâm phạm

Hầu hết người dùng không tương tác trực tiếp với hợp đồng thông minh, mà thay vào đó thực hiện qua giao diện web thông qua thiết bị di động hoặc trình duyệt web của họ.

Các giao diện frontend có thể dễ dàng bị tấn công thông qua những phương thức quen thuộc như chiếm quyền DNS, chèn mã JavaScript độc hại, lưu trữ không an toàn, hoặc thông qua nhiều gói phụ thuộc của bên thứ ba. Một ứng dụng bị xâm nhập có thể dẫn đến việc người dùng bị chuyển hướng sang các smart contract độc hại hoặc ký những giao dịch sai lệch.

1.5 Quyền riêng tư

Quyền riêng tư có thể giúp giảm thiểu hoặc làm gia tăng rủi ro bảo mật đối với mọi loại người dùng.

Các biện pháp bảo vệ quyền riêng tư yếu kém khiến người dùng cá nhân dễ bị nhiều mối đe dọa nhắm mục tiêu như lừa đảo phishing, khai thác, scam, hoặc thậm chí tấn công vật lý. Nhiều mẫu UX phổ biến cũng làm lộ thông tin người dùng, chẳng hạn như việc tái sử dụng địa chỉ, dữ liệu KYC, hay rò rỉ các loại metadata khác.

Đối với các tổ chức và doanh nghiệp, quyền riêng tư thường là một yêu cầu kinh doanh cơ bản nhằm đáp ứng các quy định tuân thủ hoặc cho những trường hợp sử dụng nhất định. Bên cạnh các yếu tố này, quyền riêng tư cũng có thể tạo ra những rủi ro bảo mật cụ thể. Ví dụ, một người dùng hệ thống chuỗi cung ứng xây dựng trên Ethereum có thể cần đến các cam kết quyền riêng tư mạnh mẽ để bảo vệ tài sản sở hữu trí tuệ — vốn có thể bị xâm hại nếu hệ thống hoạt động một cách minh bạch.

1.6 Phân mảnh

Hiện đang thiếu sự thống nhất trong cách các ví khác nhau xử lý những hành vi cốt lõi như hiển thị giao dịch, xử lý phê duyệt hay gắn nhãn hợp đồng. Sự phân mảnh trong trải nghiệm người dùng này làm gia tăng trở ngại cho việc học cách sử dụng ví một cách an toàn, đồng thời làm tăng rủi ro.

Ví dụ, người dùng không thể dựa vào các tín hiệu UX nhất quán để tự bảo vệ mình khỏi các hình thức tấn công phishing và giả mạo, vì chúng khác nhau giữa các ví. Người dùng cũng không thể kỳ vọng nhiều về cách Ethereum vận hành nếu mỗi công cụ lại hoạt động theo một cách khác nhau.

Bảo mật của hợp đồng thông minh đã được cải thiện đáng kể trong suốt lịch sử phát triển của Ethereum. Những sự cố bảo mật ban đầu như vụ hack DAO đã thúc đẩy hệ sinh thái trở nên chuyên nghiệp hóa và tăng cường các biện pháp bảo vệ trong toàn bộ vòng đời phần mềm, từ đó đảm bảo an toàn hơn cho việc triển khai mã on-chain. Những bước tiến quan trọng bao gồm:

• Kiểm toán bảo mật đã trở thành một thực tiễn tiêu chuẩn, với sự tham gia của nhiều công ty bảo mật gia nhập hệ sinh thái và phát triển chuyên môn.
• Các công cụ, hệ thống kiểm thử và phân tích tĩnh đã dần trưởng thành và trở thành thực tiễn tiêu chuẩn.
• Các thư viện chứa những thành phần phổ biến đã được kiểm toán trước mang đến cho các nhà phát triển những khối xây dựng an toàn mặc định.
• Các kỹ thuật kiểm chứng hình thức đã được áp dụng, đặc biệt cho các cầu nối, hệ thống staking và những hợp đồng có giá trị cao.
• Văn hóa bảo mật và các phương pháp thực hành tốt nhất của hệ sinh thái đã được cải thiện.
• Việc triển khai các chương trình bounty quy mô lớn đã giúp củng cố lớp ứng dụng.

Tuy nhiên, vẫn còn tồn tại những điểm yếu và những khía cạnh cần được cải thiện trong lĩnh vực này.

2.1 Các lỗ hổng hợp đồng

Dù bảo mật hợp đồng thông minh đã có nhiều bước tiến, vẫn còn tồn tại những lỗ hổng có thể dẫn đến các sự cố nghiêm trọng về an ninh, bao gồm:

• Rủi ro khi nâng cấp hợp đồng. Một số hợp đồng được thiết kế có thể chỉnh sửa sau khi triển khai, nhằm cho phép đội ngũ phát triển tiếp tục cập nhật và cải tiến ứng dụng. Tuy nhiên, điều này cũng tiềm ẩn rủi ro. Việc nâng cấp có thể tạo ra các lỗ hổng mới, hoặc trong trường hợp nâng cấp độc hại, có thể dẫn đến mất toàn bộ tài sản của người dùng.
• tái hòa nhập, trường hợp hợp đồng A gọi đến một hợp đồng B bên ngoài trước khi cập nhật trạng thái nội bộ của chính nó, và hợp đồng B lại gọi ngược trở lại hợp đồng gốc A khi lời gọi đầu tiên vẫn chưa hoàn tất.
• Việc sử dụng thư viện bên ngoài không an toàn, nơi mà một hợp đồng gọi đến thư viện bên ngoài có thể chưa được kiểm toán, chứa mã độc, hoặc có khả năng nâng cấp.
• Các thành phần chưa được kiểm toán. Mặc dù việc kiểm toán và sử dụng các thư viện chuẩn đã được cải thiện, nhưng đôi khi các nhà phát triển vẫn dựa vào những thành phần chưa được kiểm toán trong ứng dụng của họ.
• Các lỗi kiểm soát truy cập, Trường hợp quyền truy cập bị cấu hình sai hoặc được định nghĩa quá rộng, tạo điều kiện cho kẻ tấn công thực hiện các hành động độc hại.
• Truy cập trái phép, trường hợp khóa riêng tư có khả năng kiểm soát hợp đồng bị kẻ tấn công chiếm đoạt.
• Các cầu nối và tương tác xuyên chuỗi. Các cầu nối và giao thức xuyên chuỗi làm tăng thêm mức độ phức tạp, và kẻ tấn công có thể khai thác những điểm yếu trong cách truyền hoặc xác thực thông điệp xuyên chuỗi.
• Sự lạm dụng ủy quyền hoặc chữ ký của Tài khoản Sở hữu Bên ngoài (EOA). Các ứng dụng độc hại có thể lừa người dùng ký ủy quyền toàn bộ tài khoản của họ cho một bên khác, tạo điều kiện cho việc đánh cắp tài sản. Chúng cũng có thể tận dụng các thông điệp đã ký từ người dùng theo những cách không lường trước được, ví dụ như trong một cuộc tấn công phát lại (replay attack).
• Rủi ro mới xuất hiện từ các lỗi do AI tạo mã hoặc các công cụ tự động tái cấu trúc gây ra.

2.2 Trải nghiệm nhà phát triển, công cụ và ngôn ngữ lập trình

Các lỗ hổng xuất hiện trong mã đã triển khai thường bắt nguồn từ lỗi của nhà phát triển. Việc cải thiện hệ thống công cụ phát triển đã giúp việc triển khai các hợp đồng thông minh an toàn trở nên dễ dàng hơn đáng kể. Tuy nhiên, vẫn còn tồn tại nhiều vấn đề.

• Thiếu các thiết lập mặc định an toàn trong những framework phổ biến. Một số công cụ đặt ưu tiên cho tính linh hoạt hoặc tốc độ hơn là sự an toàn, dẫn đến việc thiết lập các mặc định không an toàn như cho phép phê duyệt token không giới hạn trong hàm approve(), hoặc không tích hợp sẵn các mẫu kiểm soát truy cập.
• Mã tùy chỉnh cho các cơ chế kiểm soát vận hành nâng cao. Các tổ chức với yêu cầu vận hành phức tạp thường phải tự xây dựng các tính năng cần thiết từ đầu, điều này làm gia tăng nguy cơ xuất hiện lỗ hổng. Hiện vẫn thiếu các thành phần hoặc framework chuẩn hóa và an toàn để phục vụ cho những quy trình bảo mật nâng cao.
• Phạm vi kiểm thử thiếu nhất quán trong toàn bộ hệ thống công cụ, cũng như sự thiếu các chuẩn mực trong việc áp dụng những kỹ thuật đã được kiểm chứng như fuzzing hoặc kiểm tra bất biến.
• Mức độ áp dụng các phương pháp kiểm chứng hình thức còn thấp. Các kỹ thuật kiểm chứng hình thức rất mạnh mẽ, nhưng đi kèm với đó là sự phức tạp, chi phí cao, đòi hỏi chuyên môn đặc thù và chưa được tích hợp tốt vào quy trình phát triển tiêu chuẩn. Trong khi đó, chúng hoàn toàn có thể được áp dụng sớm hơn trong quá trình sản xuất phần mềm để xác minh mức độ an toàn ngay từ giai đoạn đặc tả.
• Các vấn đề liên quan đến việc kiểm chứng hợp đồng. Người dùng và các nhà phát triển không thể dễ dàng đánh giá độ tin cậy của các hợp đồng đã triển khai, mức độ xác thực bảo mật của chúng (ví dụ: kiểm toán mã nguồn) hay sự hiện diện của những rủi ro tiềm ẩn. Mặc dù đã có các giải pháp cho mục đích này, nhưng nhiều vấn đề vẫn còn tồn tại. Các công cụ giải quyết những vấn đề này chưa được áp dụng rộng rãi, các tiêu chuẩn sẽ thống nhất các phương pháp vẫn còn phân mảnh, và một số dịch vụ hiện có lại là những sự phụ thuộc tập trung.
• Rủi ro trình biên dịch. Các trình biên dịch (phần mềm chuyển đổi mã nguồn dễ đọc cho con người như Solidity thành mã byte được sử dụng bởi EVM) có thể có những lỗi khuyết điểm, dẫn đến các lỗi trong hợp đồng thông minh trước khi chúng được triển khai. Hệ sinh thái Ethereum hiện nay chủ yếu phụ thuộc vào trình biên dịch solc, điều này có nghĩa là một lỗi có thể gây ra tác động rộng rãi.
• Độ đa dạng và chiều sâu của ngôn ngữ lập trình. Mặc dù Solidity có một hệ sinh thái công cụ phong phú được xây dựng trên đó, nhưng một số nhà phát triển muốn có những tính năng an toàn hiện đại hơn được tìm thấy trong các ngôn ngữ lập trình khác, chẳng hạn như an toàn bộ nhớ.

2.3 Mức độ rủi ro của các mã trên chuỗi

Các tổ chức và doanh nghiệp đã có các quy trình, tiêu chuẩn và yêu cầu hiện có để đánh giá tính bảo mật của công nghệ và hệ thống mà họ phụ thuộc vào. Tuy nhiên, các khuôn khổ hiện tại thường không khớp một cách rõ ràng với hợp đồng thông minh, thường giả định mã có thể thay đổi, kiểm soát thay đổi tập trung và các ranh giới rõ ràng về trách nhiệm hoặc nghĩa vụ pháp lý. Các hệ thống được xây dựng trên hợp đồng thông minh đôi khi có thể phá vỡ những giả định đó, khiến cho các tổ chức gặp khó khăn trong việc áp dụng Ethereum và quản lý rủi ro một cách thích hợp.

Các hệ thống này là bề mặt tấn công cho cả ví và lớp ứng dụng (ví dụ: các điểm cuối RPC cho ví) và cho chính giao thức Ethereum (ví dụ: nhiều trình xác thực được lưu trữ trên cơ sở hạ tầng đám mây). Sự đánh cắp khóa riêng, lừa đảo và thiếu các kiểm soát truy cập chi tiết có thể dẫn đến các sự cố quy mô lớn, đánh cắp hoặc thay đổi không được phép, ngay cả khi giao thức blockchain cơ bản vẫn an toàn.

3.1 Chuỗi layer 2

Các chuỗi Layer 2 (L2) hoạt động như các phần mở rộng cho Ethereum, cho phép môi trường giao dịch nhanh hơn và phí giao dịch thấp hơn trong khi vẫn giữ lại một số đảm bảo an ninh đặc trưng của mạng chính Ethereum (tùy thuộc vào thiết kế cụ thể của chúng). Tuy nhiên, chúng cũng có những bề mặt tấn công riêng biệt của mình, bao gồm:

• Sự phức tạp của tài sản liên kết đa bước. Khi tài sản di chuyển giữa L1 và nhiều L2, chúng phải đối mặt với nhiều bộ hợp đồng, tất cả đều phải được bảo mật. Việc kế toán không khớp hoặc sự cố trong các chuỗi L2 có thể tạo ra các lỗ hổng mà kẻ tấn công có thể khai thác.
• Các hệ thống Rollup L2 dựa vào các hệ thống chứng minh để đảm bảo tính chính xác của việc cập nhật trạng thái.. Các lỗi hoặc cấu hình sai trong những hệ thống này có thể làm chậm hoặc ngăn cản việc hoàn tất, hoặc cho phép việc hoàn tất các cập nhật trạng thái sai, dẫn đến việc mất mát tài sản của người dùng.
• Hội đồng an ninh là những nhóm người giữ chìa khóa, hoạt động như một cơ chế "dự phòng" để nâng cấp phần mềm L2 hoặc phản ứng với một số tình huống khẩn cấp. Các hội đồng an ninh bản thân họ cũng tạo ra những rủi ro, vì sự thỏa hiệp hoặc cấu kết giữa các thành viên có thể đặt quỹ của người dùng vào nguy cơ hoặc đóng băng tài sản.

Xin xem L2Beatopens in a new tab để biết thêm thông tin chi tiết về khung đánh giá và bảng giám sát, đánh giá và so sánh hiệu suất và độ an toàn của L2.

3.2 Cơ sở hạ tầng RPC và nút

Các ứng dụng Ethereum phụ thuộc vào một số nhà cung cấp cơ sở hạ tầng nhỏ để truy cập RPC, API và dịch vụ nút. Điều này bao gồm các nhà cung cấp cơ sở hạ tầng đặc thù cho tiền điện tử, cũng như các dịch vụ đám mây truyền thống thường được sử dụng để lưu trữ các nút (ví dụ: AWS, Cloudflare, Hetzner).

Nếu các nhà cung cấp hạ tầng này ngừng hoạt động hoặc cố gắng kiểm duyệt hoặc giảm tốc độ truy cập, nhiều người dùng có thể bị ngăn cản không thể truy cập Ethereum thông qua ví hoặc ứng dụng của họ, cho đến khi họ có thể chuyển sang một RPC mới hoặc nhà cung cấp hạ tầng khác. Một số nhà cung cấp này đã từng đình chỉ hoặc đóng tài khoản liên quan đến hoạt động blockchain, làm dấy lên lo ngại về độ tin cậy lâu dài của họ cho các ứng dụng phi tập trung.

3.3 Các lỗ hổng ở cấp độ DNS

Hệ thống Tên miền (DNS) là một lớp nền tảng của internet, nhưng nó cũng được tập trung và có thể bị xâm phạm. Nhiều người dùng truy cập các ứng dụng thông qua các tên miền web, mà dễ bị ảnh hưởng bởi:

• Tấn công giả mạo DNS, nơi kẻ tấn công chèn một giao diện giả mạo độc hại.
• Việc thu giữ tên miền, trong đó một chính phủ hoặc đơn vị đăng ký có thể thu giữ các tên miền.
• Lừa đảo qua các tên miền tương tự, nơi những kẻ tấn công đăng ký các tên gần giống để gây nhầm lẫn cho người dùng.

3.4 Chuỗi cung ứng phần mềm và thư viện

Các nhà phát triển Ethereum dựa vào các thư viện mã nguồn mở, thường được lấy trực tiếp từ các dịch vụ như npm, crates.io hoặc GitHub. Nếu những thư viện này bị xâm phạm, chúng có thể trở thành một vector cho các cuộc tấn công như:

• Tiêm gói độc hại, nơi mà các kẻ tấn công xâm phạm một gói phần mềm được sử dụng rộng rãi hoặc phát hành một gói với tên gọi tương tự
• Sự phụ thuộc bị đánh cắp, nơi mà những người duy trì đánh mất quyền kiểm soát một dự án và một nhân tố độc hại đưa vào mã gây hại
• Thỏa hiệp giữa các nhà phát triển, nơi các gói được cài đặt chứa mã cho phép kẻ tấn công kiểm soát máy tính của nhà phát triển.

3.5 Dịch vụ cung cấp giao diện người dùng và các rủi ro liên quan

Nhiều ứng dụng Ethereum cung cấp giao diện người dùng của họ thông qua Mạng Phân Phối Nội Dung (CDN) hoặc nền tảng lưu trữ dựa trên đám mây (ví dụ: Vercel, Netlify, Cloudflare). Nếu các dịch vụ này bị xâm phạm, chúng có thể trở thành một phương tiện cho các cuộc tấn công như tiêm mã javascript độc hại, trong đó các kẻ tấn công cung cấp một giao diện người dùng đã được thay đổi cho người dùng.

3.6 Sự kiểm duyệt ở cấp độ nhà cung cấp dịch vụ Internet

Các nhà cung cấp dịch vụ Internet (ISP) hoặc các quốc gia có thể sử dụng quyền kiểm soát hạ tầng Internet cơ sở để kiểm duyệt quyền truy cập vào Ethereum. Ví dụ, các cuộc tấn công này có thể bao gồm:

• Chặn hoặc giảm lưu lượng truy cập đến các cổng Ethereum thông dụng
• Lọc các yêu cầu DNS phân giải đến các dịch vụ liên quan đến Ethereum
• Gây rào cản địa lý hoặc cấm địa chỉ IP đối với các nút Ethereum đã được xác định
• Kiểm tra gói sâu để xác định và kiểm duyệt các lưu lượng liên quan đến giao thức Ethereum

Nhiều trong số các kỹ thuật cơ bản này đã được các chính phủ độc tài trên thế giới sử dụng để đàn áp quyền truy cập thông tin, công cụ biểu tình hoặc tiền điện tử trong thời điểm hiện tại.

Giao thức đồng thuận của Ethereum đã chứng minh tính ổn định trong thực tiễn, không có thời gian ngừng hoạt động kể từ khi ra mắt lần đầu vào năm 2015 và qua nhiều bản nâng cấp. Tuy nhiên, vẫn còn những lĩnh vực cần cải thiện trong dài hạn để làm cho hệ thống trở nên bền vững và an toàn hơn.

4.1 Độ mong manh của sự đồng thuận và rủi ro phục hồi

Các quy tắc chọn nhánh và tính xác thực của Ethereum là mạnh mẽ, nhưng không phải là không thể bị tổn thương. Trong một số trường hợp đặc biệt (như sự không đồng thuận kéo dài giữa các trình xác thực, lỗi khách hàng, hoặc phân tách mạng lưới), sự đồng thuận có thể bị trì trệ hoặc tạm thời phân kỳ. Trong các điều kiện cực đoan, điều này có thể dẫn đến việc áp dụng hình phạt cho các trình xác thực thông qua sự rò rỉ không hoạt động hoặc việc tước quyền, từ đó có thể dẫn đến sự rút lui vốn từ các trình xác thực.

4.2 Đa dạng khách hàng

Sự đa dạng khách hàng hàng đầu của Ethereum bảo vệ mạng lưới khỏi các lỗi của bất kỳ khách hàng duy nhất nào. Tuy nhiên, sự đa dạng khách hàng vẫn có thể được cải thiện thông qua việc gia tăng việc áp dụng các khách hàng thiểu số để giảm thiểu những rủi ro này xa hơn nữa.

4.3 Sự tập trung trong việc staking và ưu thế của các pool

Một lượng lớn sức nặng của validator hiện tập trung trong các giao thức staking thanh khoản, dịch vụ lưu ký và những nhà vận hành node lớn. Sự tập trung này có thể dẫn đến các rủi ro như:

• Sự chi phối hoặc thao túng quản trị. Nếu các thực thể nắm giữ lượng stake lớn (hoặc các tổ chức có quyền lực pháp lý có thể tác động đến những thực thể đó) phối hợp với nhau, họ có thể tạo ra ảnh hưởng vượt mức trong việc đề xuất và chứng thực khối, từ đó có khả năng kiểm duyệt người dùng hoặc tác động đến quá trình nâng cấp giao thức.
• Sự đồng nhất trong lựa chọn client và thiết lập cơ sở hạ tầng, có thể làm gia tăng rủi ro sự cố hàng loạt.

4.4 Cơ chế slashing xã hội chưa xác định và khoảng trống trong phối hợp

Trong một số tình huống sự cố nghiêm trọng, Ethereum sẽ phải dựa vào “slashing xã hội” để trừng phạt các validator có hành vi độc hại nhằm tấn công mạng lưới (xem mục 6.1). Tuy nhiên, cơ sở hạ tầng, chuẩn mực và quy trình dự kiến cho hình thức slashing này vẫn chưa được phát triển đầy đủ. Hiện vẫn chưa có một cơ chế nào được thiết lập để cộng đồng có thể sử dụng khi tham gia vào quá trình này.

4.5 Các hướng tấn công về kinh tế và lý thuyết trò chơi

Nhiều hướng tấn công tiềm ẩn về mặt kinh tế vẫn chưa được nghiên cứu đầy đủ, bao gồm:

• Các cuộc tấn công kiểu “griefing” hoặc “slash griefing”. Validator có thể phải chịu chi phí hoặc bị phạt slashing không phải do lỗi của họ, mà do hành vi gây hại có chủ đích, chỉ nhằm làm thiệt hại cho người khác, dù chính kẻ tấn công cũng phải chịu lỗ.
• Thoát có chiến lược hoặc ngưng hoạt động theo thời gian. Validator có thể chủ ý tắt máy hoặc thoát mạng vào những thời điểm nhạy cảm, nhằm tối đa hóa lợi nhuận hoặc gây rối đồng thuận, trong khi chỉ phải chịu mức phạt rất nhỏ.
• Thông đồng giữa các validator hoặc relay. Hành vi phối hợp giữa các validator hoặc giữa các relay và validator có thể làm giảm sự phân quyền hoặc trích xuất MEV.
• Khai thác các ưu đãi đối với những trường hợp đặc biệt trong cơ chế MEV, mô hình tách biệt proposer–builder, hoặc thiết kế staking thanh khoản. Một số tác nhân có thể lợi dụng những điều kiện hiếm gặp trong giao thức để đạt được phần thưởng lớn.

4.6 Rủi ro lượng tử

Mật mã lõi của Ethereum (ví dụ: chữ ký đường cong elliptic như secp256k1) trong tương lai có thể bị phá vỡ bởi máy tính lượng tử. Dù đây chưa phải là rủi ro trước mắt, nhưng chỉ cần xuất hiện một mối đe dọa đáng tin cậy thì các ví, hợp đồng và khóa staking hiện tại có thể ngay lập tức trở nên dễ bị tấn công. Thách thức trong tương lai này làm suy yếu các cam kết dài hạn mà Ethereum mang lại cho người dùng.

Các lộ trình chuyển dịch sang mật mã kháng lượng tử (ví dụ: thông qua các sơ đồ chữ ký hậu lượng tử) cần phải được thiết kế, thử nghiệm và có thể được tích hợp vào giao thức nhiều năm trước khi chúng trở nên cần thiết. Các tổ chức trong hệ sinh thái Ethereum, bao gồm cả Quỹ Ethereum, đang tích cực khám phá các lựa chọn này và theo dõi các rủi ro.

Ngay cả một hệ sinh thái blockchain lý tưởng cũng sẽ có những rủi ro, cuộc tấn công và lỗ hổng bảo mật . Khi có sự cố xảy ra, cần phải có những hệ thống hiệu quả để giảm thiểu, phát hiện và ứng phó. Các thách thức ở đây bao gồm:

• Tiếp cận với đội ngũ bị ảnh hưởng. Có thể hơi khó để liên lạc với đội ngũ mà ứng dụng của họ đã bị xâm phạm. Điều này có thể gây ra nhiều giờ trì hoãn, khiến cho việc khôi phục quỹ trở nên khó khăn.
• Những vấn đề ngày càng leo thang ở các tổ chức có liên quan. Khi vấn đề liên quan đến một nền tảng (như mạng xã hội hoặc sàn giao dịch tập trung), điều này có thể khiến những phản hồi viên gặp khó khăn trong việc nêu rõ vấn đề nếu họ không có một liên hệ trước đó.
• Sự phối hợp phản hồi. Thường thì không rõ có bao nhiêu đội ngũ phản ứng sự cố đang hỗ trợ ứng dụng bị ảnh hưởng, dẫn đến việc truyền đạt thông tin không rõ ràng hoặc nỗ lực bị lãng phí, trong khi một nỗ lực tập thể có thể hiệu quả hơn.
• Thiếu hụt khả năng giám sát. Việc theo dõi các vấn đề trên chuỗi và ngoài chuỗi có thể khó khăn, nhưng điều này sẽ cung cấp cảnh báo sớm và đảm bảo phản ứng nhanh chóng đối với các mối đe dọa.
• Quyền tiếp cận bảo hiểm. Bảo hiểm là một công cụ thiết yếu để giảm thiểu tổn thất trong hầu hết các hệ thống truyền thống liên quan đến tiền tệ, hệ thống tài chính, danh tính và các thông tin giá trị khác. Tuy nhiên, hiện nay có rất ít lựa chọn bảo hiểm từ các dịch vụ tài chính truyền thống cho hệ sinh thái tiền điện tử.

Những rủi ro này có xu hướng liên quan đến dài hạn hơn, và liên quan đến Ethereum nói chung thay vì bảo mật của từng người dùng hoặc ứng dụng.

6.1 Cổ phần tập trung

Việc tập trung một lượng lớn tài sản có thể gây rủi ro cho toàn bộ Ethereum nếu những người kiểm soát tài sản đó quyết định hợp tác với nhau.
Sự tập trung kinh tế này tạo ra tiềm năng cho việc chiếm đoạt quản lý xã hội. Nếu một nhóm nhỏ các xác nhận viên kiểm soát một phần lớn cổ phần, họ có thể:

• Phối hợp hoặc kháng cự các điểm phân nhánh.
• Kiểm duyệt một số giao dịch hoặc hợp đồng.
• Hủy hoại sự đồng thuận của cộng đồng bằng cách đe dọa rút lui hoặc phản đối.

Nếu kịch bản cực đoan này xảy ra, cộng đồng Ethereum đã gợi ý rằng "cắt giảm xã hội" có thể là lời giải. Cắt giảm xã hội là việc sử dụng sự đồng thuận xã hội ngoài chuỗi để quyết định việc cắt giảm những người xác thực không đúng quy tắc, như một cách kiểm soát quyền lực của họ. Nhưng hiện tại thì vẫn chưa có quy tắc, quy trình hay công cụ rõ ràng nào để thực hiện những biện pháp như vậy (xem phần 4.4).

6.2 Tài sản tập trung ngoài chuỗi

Ethereum chứa một lượng lớn tài sản thực tế, nơi các tài sản này được giữ ngoài chuỗi trong các tài khoản ngân hàng hoặc các khoản gửi khác, sau đó được giao dịch trên chuỗi thông qua các token đại diện cho quyền sở hữu tài sản ngoài chuỗi. Chẳng hạn, nhiều stablecoin lớn hoạt động theo cách này.

Các tổ chức nắm giữ khoản tiền gửi ngoài chuỗi có thể có ảnh hưởng đến hệ sinh thái Ethereum. Chẳng hạn, trong một kịch bản cực đoan khi có một phân nhánh gây tranh cãi hoặc nâng cấp mạng, những người gửi tiền lớn có thể ảnh hưởng đến việc chuỗi nào được chấp nhận rộng rãi chỉ bằng cách chọn công nhận token trên một chuỗi hoặc chuỗi khác.

6.3 Quy định về áp lực hoặc tấn công

Các chính phủ và cơ quan quản lý có thể gây áp lực lên các thực thể khác nhau kiểm soát các thành phần quan trọng của nền tảng Ethereum để cấm hoặc can thiệp vào giao thức Ethereum. Các người dùng tổ chức của Ethereum cũng có thể bị ảnh hưởng bởi những áp lực này, điều này sẽ có những hệ quả tiếp theo đối với người dùng của họ (ví dụ, một ngân hàng không còn có thể cung cấp một số sản phẩm liên quan đến tiền điện tử do các lệnh cấm quy định).

6.4 Sự chiếm đoạt tổ chức trong quản trị

Quy trình quản trị và phát triển mã nguồn mở của Ethereum được thúc đẩy bởi một tập hợp đa dạng và toàn cầu các đội ngũ và công ty giữ vai trò duy trì phần mềm khách hàng cốt lõi, cơ sở hạ tầng và công cụ.

Các hình thức ảnh hưởng khác nhau (như việc mua lại doanh nghiệp, phụ thuộc vào tài trợ, tuyển dụng những người đóng góp chủ chốt, xung đột lợi ích trong các tổ chức hiện tại) có thể dần dần làm thay đổi văn hóa và ưu tiên trong quản trị Ethereum. Điều này có thể dẫn đến sự phù hợp với các lợi ích thương mại hoặc bên ngoài cụ thể, khác biệt với tinh thần cộng đồng và lộ trình đã được thiết lập, tiềm ẩn khả năng làm suy yếu sự trung lập và khả năng chống chịu của Ethereum theo thời gian.