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

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

Do đó, một gánh nặng bảo mật đáng kể đè lên người dùng. Để sử dụng Ethereum một cách an toàn, các cá nhân và tổ chức phải nắm giữ và quản lý các 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 các khóa của họ để ký các giao dịch nhằm chuyển 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 các rủi ro như lộ hoặc mất khóa, các chấp thuận 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 quá trình 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ý an toàn các khóa mật mã.

Hầu hết các ví phần mềm được sử dụng rộng rãi đều dựa vào việc người dùng lưu trữ an toàn các cụm từ hạt giống đại diện cho khóa riêng tư 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 giải pháp thay thế không an toàn như lưu trữ các cụm từ hạt giống dưới dạng văn bản thuần túy, trên các dịch vụ đám mây hoặc viết chúng ra giấy.

Ví phần cứng là một giải pháp thay thế, cho phép người dùng quản lý một khóa mật mã đượ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ó những lỗ hổng 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 chuỗi cung ứng nơi các thiết bị bị xâm phạm được bán ra thị trường.

Cho dù các 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ó thể hiểu được là cảm thấy lo lắng về việc tự lưu ký khi nó có thể bị xâm phạm thông 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ữ các khóa (ví dụ: như 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 những khóa mới do những thay đổi về nhân sự theo thời gian. Các yêu cầu tuân thủ trong các ngành và khu vực pháp lý khác nhau có thể yêu cầu các quy trình làm việc tùy chỉnh hoặc dấu vết kiểm toán không được hỗ trợ bởi phần mềm ví hiện có. Trong một số trường hợp, người dùng doanh nghiệp chuyển sang các bên lưu ký thứ ba cho các tài sản kỹ thuật số, điều này có thể đưa ra một lớp rủi ro bảo mật khác cần xem xét.

1.2 Việc ký mù & sự không chắc chắn của giao dịch

Người dùng thường xuyên chấp thuận các giao dịch một cách "mù quáng" mà không hiểu họ đang làm gì. Các ví thường trình bày dữ liệu thập lục phân thô, địa chỉ hợp đồng bị cắt bớt 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 nhất định. Điều này khiến mọi loại người dùng dễ bị tổn thương trước các hợp đồng thông minh độc hại, lừa đảo, gian lận, giao diện giả mạo, sự xâm phạm giao diện người dùng (front-end) và các lỗi cơ bản của người dùng.

1.3 Quản lý sự chấp thuận và quyền

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

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

Điều này có thể khiến người dùng gặp rủi ro trước các ứng dụng độc hại hoặc các giao diện người dùng bị xâm phạm, bởi vì thói quen mặc định của nhiều người dùng là cấp các sự chấp thuận không giới hạn có thể được sử dụng để rút cạn tiền của họ. Ngay cả khi một người dùng cấp một sự chấp thuậ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 sự chấp thuận vẫn còn hiệu lực, thì hợp đồng bị xâm phạm đó có thể rút cạn tiền của người dùng.

Đây cũng là một rủi ro đối với người dùng tổ chức. Ví dụ: một tổ chức có thể chọn cấp cho một bộ định tuyến DEX hạn mức USDC không giới hạn để thuận tiện cho hoạt động, điều này sau đó khiến họ gặp rủi ro nếu hợp đồng 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 một hợp đồng thông minh, mà thông qua một giao diện web qua thiết bị di động hoặc trình duyệt web của họ.

Các giao diện người dùng này có thể dễ bị tấn công thông qua các phương tiện quen thuộc như chiếm đoạt DNS, tiêm mã JavaScript độc hại, lưu trữ không an toàn hoặc các phụ thuộc bên thứ ba khác nhau. Một UX ứng dụng bị xâm phạm có thể chuyển hướng mọi loại người dùng đến các hợp đồng thông minh độc hại hoặc dẫn họ đến việc ký các giao dịch gây hiểu lầm.

1.5 Quyền riêng tư

Quyền riêng tư có thể giảm thiểu hoặc phóng đại các rủi ro bảo mật cho mọi loại người dùng.

Các biện pháp bảo vệ quyền riêng tư yếu hơn khiến người dùng cá nhân gặp phải nhiều mối đe dọa có mục tiêu như lừa đảo, bóc lột, gian lận hoặc các cuộc tấn công vật lý. Nhiều mẫu UX phổ biến làm lộ thông tin người dùng, ví dụ: việc tái sử dụng địa chỉ, dữ liệu KYC và các rò rỉ siêu dữ liệu 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 vì lý do tuân thủ hoặc một số trường hợp sử dụng nhất định. Ngoài những vấn đề đó, nó có thể tạo ra sự phơi nhiễm với các rủi ro bảo mật cụ thể. Ví dụ: một người dùng của một hệ thống chuỗi cung ứng được xây dựng trên Ethereum có thể yêu cầu các đảm bảo quyền riêng tư mạnh mẽ để bảo vệ các tài sản sở hữu trí tuệ có thể bị xâm phạm nếu hệ thống minh bạch.

1.6 Sự phân mảnh

Có sự thiếu nhất quán trong cách các ví khác nhau xử lý các hành vi cốt lõi như hiển thị các giao dịch, xử lý các sự chấp thuận hoặc dán nhãn các hợp đồng. Sự phân mảnh trải nghiệm người dùng này làm tăng thêm trở ngại cho khả năng của người dùng trong việc học cách sử dụng ví một cách an toàn và làm tăng các 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 để bảo vệ bản thân khỏi lừa đảo và giả mạo vì chúng khác nhau giữa các ví. Người dùng không thể hình thành những kỳ vọng đáng tin cậy về cách Ethereum hoạt động nếu mỗi công cụ hoạt động khác nhau.

Bảo mật hợp đồng thông minh đã được cải thiện triệt để trong suốt lịch sử của Ethereum. Các sự cố bảo mật ban đầu như vụ hack DAO đã thúc đẩy hệ sinh thái chuyên nghiệp hóa và cải thiện các biện pháp bảo vệ trong suốt vòng đời phần mềm dẫn đến việc mã được triển khai trên chuỗi. Các tiến bộ chính 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 một số công ty bảo mật tham gia vào hệ sinh thái và phát triển chuyên môn.
• Công cụ, thử nghiệm và các hệ thống phân tích tĩnh đã trưởng thành và trở thành thực tiễn tiêu chuẩn.
• Các thư viện của các thành phần chung đã được kiểm toán trước đã cung cấp cho các nhà phát triển các khối xây dựng an toàn theo mặc định.
• Các kỹ thuật xác minh hình thức đã được áp dụng, đặc biệt là đối với các cầu nối, hệ thống đặt cọc và các hợp đồng có giá trị cao.
• Văn hóa bảo mật và các thực tiễn tốt nhất của hệ sinh thái đã được cải thiện.
• Việc tạo ra các chương trình tiền thưởng đáng kể đã củng cố lớp ứng dụng.

Tuy nhiên, vẫn còn những điểm yếu và các lĩnh vực cần cải thiện trong lĩnh vực này.

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

Bất chấp những tiến bộ trong bảo mật hợp đồng thông minh, vẫn có những lỗ hổng có thể dẫn đến các vấn đề bảo mật đáng kể, bao gồm:

• Rủi ro nâng cấp hợp đồng. Một số hợp đồng được thiết kế để có thể sửa đổi sau khi triển khai, nhằm cho phép một nhóm phát triển tiếp tục cập nhật và cải thiện một ứng dụng. Tuy nhiên, điều này đưa ra các rủi ro. Các bản nâng cấp có thể dẫn đến các lỗ hổng mới hoặc mất hoàn toàn tiền của người dùng trong trường hợp có một bản nâng cấp độc hại.
• Tái xâm nhập (Re-entrancy), nơi hợp đồng A gọi 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 gọi lại hợp đồng A ban đầu trước khi lệnh gọi đầu tiên kết thúc.
• Sử dụng không an toàn các thư viện bên ngoài, nơi một hợp đồng gọi một thư viện bên ngoài có thể chưa được kiểm toán, độc hại hoặc có thể 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 tiêu chuẩn đã được cải thiện, các nhà phát triển đôi khi vẫn dựa vào các thành phần chưa được kiểm toán trong các ứng dụng của họ.
• Các lỗi kiểm soát truy cập, nơi các quyền bị định cấu hình sai hoặc được xác định quá rộng, cho phép những kẻ tấn công thực hiện các hành động độc hại.
• Truy cập trái phép, nơi một khóa riêng tư có khả năng kiểm soát hợp đồng bị một tác nhân độc hại lấy được.
• Các cầu nối và tương tác chéo chuỗi. Các cầu nối và giao thức chéo chuỗi đưa ra sự phức tạp bổ sung, và những kẻ tấn công có thể khai thác các điểm yếu trong cách các tin nhắn chéo chuỗi được truyền đi hoặc được xác thực.
• Lạm dụng sự ủy quyền hoặc chữ ký của Tài khoản thuộc 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ý giao toàn bộ sự ủy quyền tài khoản của họ cho một bên khác, tạo điều kiện cho việc trộm cắp. Các ứng dụng độc hại cũng có thể sử dụng các tin nhắn đã ký từ người dùng theo những cách không mong muốn, ví dụ: trong một cuộc tấn công phát lại.
• Rủi ro mới nổi về các lỗi do việc tạo mã AI hoặc các công cụ tái cấu trúc tự động đưa vào.

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 cuối cùng xuất hiện trong mã được triển khai là do lỗi của nhà phát triển. Công cụ dành cho nhà phát triển được cải thiệ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, các vấn đề vẫn còn.

• Thiếu các mặc định an toàn trong các khuôn khổ phổ biến. Một số công cụ ưu tiên tính linh hoạt hoặc tốc độ hơn sự an toàn, thiết lập các mặc định không an toàn như các sự chấp thuận token không giới hạn trong hàm approve(), hoặc không bao gồm các mẫu kiểm soát truy cập theo mặc định.
• Mã tùy chỉnh cho các kiểm soát hoạt động nâng cao. Người dùng tổ chức với các yêu cầu hoạt động phức tạp thường phải xây dựng các tính năng cần thiết từ đầu, làm tăng rủi ro về các lỗ hổng. Có sự thiếu hụt các thành phần hoặc khuôn khổ an toàn được tiêu chuẩn hóa cho các quy trình bảo mật nâng cao.
• Phạm vi thử nghiệm không nhất quán trên các ngăn xếp công cụ, cũng như thiếu các chuẩn mực xung quanh việc sử dụng các kỹ thuật đã được chứng minh như fuzzing hoặc kiểm tra bất biến.
• Mức độ áp dụng các phương pháp xác minh hình thức thấp. Các kỹ thuật xác minh hình thức rất mạnh mẽ, nhưng chúng phức tạp, tốn kém, yêu cầu chuyên môn miền chuyên biệt và không được tích hợp tốt vào các quy trình làm việc tiêu chuẩn của nhà phát triển, nơi chúng có thể được sử dụng sớm hơn nhiều trong quá trình sản xuất phần mềm để xác minh sự an toàn ở giai đoạn đặc tả.
• Các vấn đề liên quan đến việc xác minh hợp đồng. Người dùng và nhà phát triển không thể dễ dàng đánh giá độ tin cậy của các hợp đồng đã được triển khai, mức độ xác thực bảo mật của chúng (ví dụ: kiểm toán mã) hoặc sự hiện diện của các rủi ro tiềm ẩn. Mặc dù có các giải pháp cho mục đích này, nhiều vấn đề vẫn còn. Công cụ giải quyết các vấn đề này không được áp dụng rộng rãi, các tiêu chuẩn có thể thống nhất các phương pháp tiếp cận vẫn còn bị phân mảnh và một số dịch vụ hiện có bản thân chúng là các phụ thuộc tập trung.
• Rủi ro từ trình biên dịch. Các trình biên dịch (phần mềm chuyển đổi mã con người có thể đọc được như Solidity thành mã byte được chính EVM sử dụng) có thể có những lỗ hổng gây ra lỗi cho các hợp đồng thông minh trước khi chúng được triển khai. Hệ sinh thái Ethereum ngày 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 những ảnh hưởng trên diện rộng.
• Sự đ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ụ chuyên sâu được xây dựng trên đó, một số nhà phát triển vẫn muốn có các 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 Đánh giá rủi ro của mã trên chuỗi

Các tổ chức và doanh nghiệp đã có sẵn các quy trình, tiêu chuẩn và yêu cầu để đá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 hoàn toàn phù hợp với các hợp đồng thông minh, do chúng thường giả định mã có thể thay đổi, kiểm soát thay đổi tập trung và có ranh giới rõ ràng về trách nhiệm giải trình hoặc trách nhiệm 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 đó, gây khó khăn cho các tổ chức trong việc áp dụng Ethereum và quản lý rủi ro một cách phù hợp.

Các hệ thống này là bề mặt tấn công đối với cả lớp ví và ứng dụng (ví dụ: các điểm cuối RPC cho ví) cũng như đối với 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). Việc lộ khóa riêng tư, lừa đảo và thiếu các kiểm soát truy cập chi tiết có thể dẫn đến tình trạng ngừng hoạt động trên quy mô lớn, trộm cắp hoặc các thay đổi trái phép, ngay cả khi giao thức chuỗi khối cơ sở vẫn an toàn.

3.1 Các chuỗi lớp 2 (l2)

Các chuỗi lớp 2 (l2) đóng vai trò là phần mở rộng cho Ethereum, mang lại môi trường giao dịch nhanh hơn và phí thấp hơn trong khi vẫn giữ được một số đảm bảo bảo mật đặ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ó các bề mặt tấn công riêng biệt bao gồm:

• Sự phức tạp của tài sản được bắc cầu qua nhiều bước. Khi tài sản di chuyển giữa L1 và nhiều L2, chúng phải tiếp xúc với nhiều bộ hợp đồng và tất cả đều phải an toàn. Sự sai lệch trong hạch toán hoặc ngừng hoạt động ở 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 L2 Rollup dựa vào các hệ thống chứng minh để thực thi tính chính xác của các bản cập nhật trạng thái. Lỗi hoặc cấu hình sai trong các hệ thống này có thể làm đình trệ hoặc ngăn cản quá trình hoàn tất, hoặc cho phép hoàn tất các bản cập nhật trạng thái sai lệch dẫn đến việc mất tiền của người dùng.
• Hội đồng bảo mật là các nhóm người nắm giữ khóa đóng vai trò như một cơ chế "dự phòng" để nâng cấp phần mềm L2 hoặc ứng phó với một số trường hợp khẩn cấp nhất định. Bản thân các hội đồng bảo mật cũng tiềm ẩn rủi ro, vì sự thỏa hiệp hoặc thông đồng giữa các thành viên có thể gây rủi ro cho tiền của người dùng hoặc đóng băng tài sản.

Xem L2BEAT (opens in a new tab) để biết khuôn khổ chi tiết và bảng điều khiển giám sát giúp đánh giá và so sánh hiệu suất cũng như tính bảo mật 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ố ít nhà cung cấp cơ sở hạ tầng để truy cập RPC, API và các dịch vụ nút. Điều này bao gồm các nhà cung cấp cơ sở hạ tầng dành riêng cho tiền mã hóa, 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 cơ sở hạ tầng này ngoại tuyến hoặc cố gắng kiểm duyệt hay bóp băng thông truy cập, nhiều người dùng có thể bị ngăn truy cập vào 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 cơ sở hạ tầng khác. Một số nhà cung cấp này trước đây đã đình chỉ hoặc đóng cửa các tài khoản liên quan đến hoạt động chuỗi khối, làm dấy lên lo ngại về độ tin cậy lâu dài của họ đối với các ứng dụng phi tập trung.

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

Hệ thống phân giải tên miền (DNS) là một lớp nền tảng của internet, nhưng nó cũng mang tính 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 miền web, vốn dễ bị ảnh hưởng bởi:

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

3.4 Chuỗi cung ứng phần mềm và các 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 các thư viện này bị xâm phạm, chúng có thể trở thành một phương thức cho các cuộc tấn công như:

• Tiêm gói độc hại, trong đó những kẻ tấn công xâm phạm một gói được sử dụng rộng rãi hoặc xuất bản một gói dưới một tên tương tự
• Chiếm đoạt các phần phụ thuộc, trong đó những người duy trì mất quyền kiểm soát một dự án và một tác nhân độc hại đưa mã gây hại vào
• Xâm phạm nhà phát triển, trong đó các gói được cài đặt chứa mã cung cấp cho kẻ tấn công quyền kiểm soát máy tính của nhà phát triển.

3.5 Các dịch vụ phân phối giao diện người dùng và rủi ro liên quan

Nhiều ứng dụng Ethereum phân phối 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 thức cho các cuộc tấn công như tiêm mã javascript độc hại, trong đó những kẻ tấn công cung cấp một giao diện người dùng đã bị thay đổi cho người dùng.

3.6 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 cơ sở hạ tầng internet cơ bản để 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 bóp băng thông lưu lượng truy cập đến các cổng Ethereum phổ biến
• Lọc các yêu cầu DNS phân giải đến các dịch vụ liên quan đến Ethereum
• Giới hạn địa lý hoặc cấm IP đối với các nút Ethereum đã biết
• Kiểm tra gói tin sâu để xác định và kiểm duyệt lưu lượng truy cập liên quan đến giao thức Ethereum

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

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

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

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

4.2 Sự đa dạng máy khách

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

4.3 Sự tập trung hóa việc đặt cọc và sự thống trị của các nhóm

Một lượng lớn trọng số của trình xác thực tập trung vào các giao thức đặt cọc thanh khoản, dịch vụ lưu ký và các nhà điều hành nút lớn. Sự tập trung này có thể dẫn đến các rủi ro như:

• Thâu tóm hoặc ảnh hưởng đến quản trị. Nếu các thực thể kiểm soát lượng lớn khoản đặt cọc (hoặc các thực thể có quyền lực pháp lý để tác động đến các thực thể đó) phối hợp với nhau, họ có thể có ảnh hưởng quá lớn đến việc các khối nào được đề xuất và chứng thực, có khả năng kiểm duyệt người dùng hoặc ảnh hưởng đến các bản nâng cấp giao thức.
• Sự đồng nhất trong việc lựa chọn máy khách và thiết lập cơ sở hạ tầng, điều này có thể làm tăng rủi ro lỗi tương quan.

4.4 Cắt giảm xã hội không xác định và những khoảng trống trong phối hợp

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

4.5 Các phương thức tấn công kinh tế và lý thuyết trò chơi

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

• Các cuộc tấn công phá hoại (griefing) hoặc phá hoại bằng phạt cắt giảm. Các trình xác thực có thể phải chịu chi phí hoặc hình phạt cắt giảm không phải do lỗi của chính họ mà do hành vi thù địch chỉ nhằm mục đích gây hại cho người khác với một khoản chi phí ròng đối với kẻ tấn công.
• Thoát chiến lược hoặc không hoạt động có tính toán. Các trình xác thực có thể cố ý ngoại tuyến hoặc thoát vào những thời điểm quan trọng để tối đa hóa lợi nhuận hoặc phá vỡ sự đồng thuận với các hình phạt tối thiểu.
• Sự thông đồng giữa các trình xác thực hoặc các rơ-le. Hành vi phối hợp giữa các trình xác thực hoặc giữa các rơ-le và trình xác thực có thể làm giảm sự phi tập trung hoặc trích xuất MEV.
• Khai thác các ưu đãi trong trường hợp ngoại lệ của MEV, tách biệt người đề xuất và người xây dựng (PBS) hoặc thiết kế đặt cọc thanh khoản. Các tác nhân có thể thao túng các điều kiện giao thức hiếm gặp để đạt được phần thưởng vượt trội.

4.6 Rủi ro lượng tử

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

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

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

• Tiếp cận nhóm bị ảnh hưởng. Có thể rất khó để liên lạc với nhóm có ứng dụng đã bị xâm phạm. Điều này có thể dẫn đến sự chậm trễ hàng giờ đồng hồ, hạn chế khả năng thu hồi tiền của những người ứng phó.
• Báo cáo sự cố lên các tổ chức liên quan. Khi sự cố 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), những người ứng phó có thể gặp khó khăn trong việc báo cáo sự cố lên cấp cao hơn nếu họ không có liên hệ từ trước.
• Phối hợp ứng phó. Thường không rõ có bao nhiêu nhóm ứng phó sự cố đang hỗ trợ ứng dụng bị ảnh hưởng, dẫn đến thông tin sai lệch hoặc lãng phí công sức trong khi một nỗ lực nhóm có thể đã hiệu quả hơn.
• Thiếu khả năng giám sát. Có thể rất khó để giám sát các vấn đề trên chuỗi và ngoài chuỗi, vốn 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.
• 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 có giá trị khác. Tuy nhiên, ngày 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 dành cho hệ sinh thái tiền mã hóa.

Những rủi ro này có xu hướng mang tính định hướng dài hạn hơn và liên quan đến toàn bộ Ethereum thay vì tính bảo mật của từng người dùng hoặc ứng dụng riêng lẻ.

6.1 Sự tập trung hóa khoản đặt cọc

Sự tập trung hóa một lượng lớn khoản đặt cọc có thể gây rủi ro cho toàn bộ Ethereum nếu các thực thể kiểm soát khoản đặt cọc đó quyết định thông đồng.
Sự tập trung hóa kinh tế này tạo ra tiềm năng thâu tóm quản trị xã hội. Nếu một nhóm nhỏ các trình xác thực kiểm soát đa số tuyệt đối khoản đặt cọc, họ có thể:

• Phối hợp thực hiện hoặc chống lại các phân nhánh.
• Kiểm duyệt một số giao dịch hoặc hợp đồng nhất định.
• Làm suy yếu sự đồng thuận của cộng đồng bằng cách đe dọa thoát 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à câu trả lờ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 phạt cắt giảm các trình xác thực có hành vi sai trái, như một cách để kiểm soát quyền lực của họ. Nhưng không có chuẩn mực, quy trình hoặc công cụ rõ ràng nào tồn tại để ban hành các biện pháp như vậy (xem phần 4.4).

6.2 Sự tập trung hóa tài sản ngoài chuỗi

Ethereum lưu trữ một lượng lớn tài sản thế giới thực (RWA), trong đó các tài sản được giữ ngoài chuỗi trong các tài khoản ngân hàng hoặc các khoản tiề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 yêu cầu nhận đối với các tài sản ngoài chuỗi. Ví dụ, nhiều stablecoin lớn hoạt động theo cách này.

Các tổ chức nắm giữ các khoản tiền gửi ngoài chuỗi có thể có ảnh hưởng đến hệ sinh thái Ethereum. Ví dụ, trong một kịch bản cực đoan khi có một đợt phân nhánh hoặc nâng cấp mạng lưới gây tranh cãi, 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 bằng cách chỉ chọn công nhận các token trên chuỗi này hoặc chuỗi kia.

6.3 Tấn công hoặc áp lực từ quy định

Các chính phủ và cơ quan quản lý có thể gây áp lực lên nhiều thực thể kiểm soát các thành phần quan trọng của ngăn xếp Ethereum để kiểm duyệt hoặc can thiệp vào giao thức Ethereum. Những 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ẽ gây ra những hậu quả sâu xa hơn cho 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 tiền mã hóa nhất định do các lệnh cấm theo quy định).

6.4 Sự thâu tóm quản trị của tổ chức

Các quy trình phát triển và quản trị 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 gồm các nhóm và công ty duy trì phần mềm máy khách cốt lõi, cơ sở hạ tầng và công cụ.

Nhiều hình thức ảnh hưởng khác nhau (mua lại doanh nghiệp, phụ thuộc vào nguồn tài trợ, tuyển dụng những người đóng góp chính, xung đột lợi ích bên 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à các ưu tiên của quản trị Ethereum. Điều này có thể dẫn đến sự liên kết với các lợi ích thương mại hoặc bên ngoài cụ thể đi ngược lại với đặc tính do cộng đồng thúc đẩy và lộ trình đã được thiết lập, có khả năng làm suy yếu tính trung lập và khả năng phục hồi của Ethereum theo thời gian.