Người sáng lập Arbitrum: Ba giải pháp cho các cuộc tấn công trì hoãn tổng hợp

Tiêu đề gốc: " Người sáng lập Arbitrum: Ba giải pháp cho các cuộc tấn công trì hoãn tổng hợp 》

Tác giả gốc: Ed Felten, Người đồng sáng lập Offchain Labs 

Bài tổng hợp gốc: Đạo của DeFi

Những điều mà các nhà thiết kế giao thức Rollup phải đối mặt Một vấn đề tế nhị là làm thế nào để đối phó với các cuộc tấn công trì hoãn. Trong bài viết này, tôi sẽ thảo luận về chúng là gì và cách Arbitrum bảo vệ chống lại chúng, dẫn đến một số phát triển mới thú vị.

Tấn công trì hoãn là các hành động độc hại nhằm ngăn chặn tiến trình của giao thức Rollup. Chúng không tấn công tính bảo mật của giao thức, nghĩa là chúng không cố gắng để buộc xác nhận thất bại. Kết quả đúng. Ngược lại, các cuộc tấn công trì hoãn tấn công tính sống động của giao thức bằng cách cố gắng ngăn chặn hoặc trì hoãn việc xác nhận bất kỳ kết quả nào.

Những vấn đề này có thể rất tinh vi. Thành thật mà nói, các nhà thiết kế giao thức thường không thích nói về các cuộc tấn công trì hoãn, nhưng mọi hệ thống Lớp 2, cho dù đó là Lạc quan Rollup, ZK Rollup hay nói cách khác, có các vấn đề xung quanh sự chậm trễ và tiến trình giao thức cần được giải quyết.

Bài viết này xem xét sâu hơn về vấn đề tấn công trì hoãn và thảo luận cách các phiên bản khác nhau của giao thức tổng hợp Arbitrum giải quyết vấn đề này.

Tấn công trì hoãn là gì?

Trong một cuộc tấn công trì hoãn, một bên độc hại (hoặc một nhóm các bên độc hại) trong Rollup giao thức Thực hiện hành động trong phạm vi, tuân theo các chiến lược được thiết kế để cản trở hoặc trì hoãn việc trả lại kết quả xác nhận cho chuỗi L1.

Điều này khác với cuộc tấn công từ chối dịch vụ (DoS), trong đó kẻ tấn công cố gắng ngăn chặn bất kỳ hành động nào được thực hiện trong giao thức. Ngược lại, trong một cuộc tấn công trì hoãn, hành động vẫn tiếp tục xảy ra, nhưng kẻ tấn công hành xử theo cách ngăn chặn hoặc trì hoãn việc xác nhận kết quả (tức là trì hoãn việc rút tài sản về L1) và buộc những người xác nhận trung thực phải đốt gas.

Bất kỳ giao thức Rollup nào có vẻ hợp lý đều yêu cầu người tham gia đặt cược, do đó, việc trì hoãn kẻ tấn công chắc chắn sẽ mất một hoặc nhiều cổ phần. Ở đây, chúng tôi giả định rằng kẻ tấn công sẵn sàng hy sinh vốn sở hữu trong giới hạn nhất định để theo đuổi cuộc tấn công của họ.

Chúng tôi cũng sẽ giả định một cách thận trọng rằng kẻ tấn công có lợi thế trong việc đưa các giao dịch vào chuỗi, vì vậy bất cứ khi nào kẻ tấn công cạnh tranh với một bên trung thực để có được mức độ ưu tiên Khi nào là nhất định, kẻ tấn công luôn thắng.

Cuối cùng, chúng tôi giả định rằng kẻ tấn công có thể kiểm duyệt quyền truy cập vào chuỗi khối L1 cơ bản để loại trừ các giao dịch Tổng hợp, nhưng chỉ trong một khoảng thời gian giới hạn mà chúng tôi gọi là " "Thời gian thử thách" . Cụ thể, kẻ tấn công có thể kích hoạt và vô hiệu hóa một "chế độ kiểm duyệt" danh nghĩa. Khi chế độ kiểm duyệt được bật, kẻ tấn công có toàn quyền kiểm soát giao dịch nào đạt đến L1. Tuy nhiên, kẻ tấn công chỉ có thể kích hoạt chế độ kiểm duyệt trong một khoảng thời gian thử thách. (Chúng tôi giả định rằng bất kỳ tập hợp giai đoạn nào của chế độ kiểm duyệt cộng lại thành nhiều giai đoạn thử thách sẽ gây ra phản ứng xã hội trong cộng đồng L1 nhằm ngăn chặn các nỗ lực kiểm duyệt.)

Đánh giá các giao thức chống lại các cuộc tấn công bị trì hoãn

Đang được đánh giá Khi ký kết thỏa thuận, chúng ta có thể đặt sáu câu hỏi:

Thỏa thuận có cơ chế chống gian lận không? (Nếu không, các cuộc tấn công trì hoãn sẽ được tranh luận vì người tham gia không thể trì hoãn việc xác nhận bất kỳ kết quả nào—kể cả những kết quả gian lận.)

Có tập trung hóa không? , ngăn chặn tiến trình bằng cách dừng hoặc giữ lại dữ liệu? Nếu vậy, phía đó có thể gây ra sự chậm trễ vô hạn.

Giao thức có cung cấp sự đảm bảo đáng tin cậy về tiến độ cuối cùng không? Nói cách khác, liệu một tác nhân trung thực có thể thúc đẩy tiến trình cuối cùng bất kể kẻ tấn công có làm gì không?

Nếu giao thức đảm bảo các quy trình không cần tin cậy thì giới hạn trên về độ trễ mà kẻ tấn công có thể gây ra là bao nhiêu?

Tổn thất mà kẻ tấn công phải trả tỷ lệ thuận với độ trễ gây ra như thế nào?

Tổng chi phí cho phản ứng của bên trung thực được đo lường như thế nào?

Sau khi thiết lập được các tiêu chí này, hãy cùng đánh giá hai phiên bản lịch sử của giao thức tổng hợp Arbitrum.

Giao thức 1: Thỏa thuận về bài viết học thuật

Một bài báo học thuật của Arbitrum năm 2018 gần như sử dụng giao thức sau (bỏ qua các mẫu nhất quán không liên quan). Bất kỳ người đặt cược nào cũng có thể nhấn mạnh vào kết quả được đề xuất, mà chúng tôi gọi là khẳng định. Trong một khoảng thời gian, bất kỳ tập hợp con nào của những người đặt cược khác đều có thể thách thức một khẳng định và người khẳng định phải bảo vệ khẳng định của mình trước từng người thách thức, mỗi lần một người thách thức. Kết thúc mỗi thử thách, bên thua cuộc sẽ mất tiền cược.

thua một thử thách mà họ "nên" thắng. Đưa cho mỗi người thách đấu một thử thách riêng biệt đảm bảo rằng người thách thức trung thực có thể đánh bại một khẳng định sai, bất kể có bao nhiêu bên ác ý cố tình thua thử thách.)

Nếu không có thử thách nào hoặc người khẳng định thắng tất cả thử thách thì xác nhận đó sẽ được xác nhận và giao thức sẽ tiếp tục. Nhưng nếu người xác nhận thua bất kỳ thử thách nào, xác nhận của nó sẽ bị từ chối và trạng thái giao thức sẽ quay trở lại trạng thái trước khi xác nhận được thực hiện.

Đánh giá

Giao thức có bằng chứng gian lận hợp lệ nhưng không đảm bảo tiến độ do Người tham gia có ý đồ xấu có thể đưa ra những xác nhận không chính xác liên tục, hy sinh vốn chủ sở hữu mỗi lần đặt cược, nhưng dẫn đến một vòng lặp vô tận của việc đưa ra và từ chối những xác nhận giống nhau, dẫn đến việc quay vòng liên tục và thiếu tiến bộ.

Giao thức 2: Rẽ nhánh và cắt tỉa

Giao thức Arbitrum hiện tại (được triển khai trên mọi phiên bản Arbitrum kể từ năm 2020) cải thiện giao thức trước đó bằng cách giới thiệu các nhánh. Ý tưởng là cho phép nhiều người đặt cược đưa ra các xác nhận cạnh tranh và coi các xác nhận cạnh tranh như các chuỗi phân nhánh. Sau đó, một loạt thử thách sẽ đặt các cành vào nhau, cuối cùng cắt tỉa tất cả trừ một trong các cành và cho phép xác nhận cành còn lại.

Phương pháp cụ thể như sau. Mỗi khối Rollup trong blockchain theo dõi dấu thời gian khi khối con đầu tiên của nó (tức là khối kế thừa) được tạo bởi người đặt cọc. Những người đặt cược khác có thể tạo các khối phụ bổ sung. Mỗi vị từ phụ đều ngầm tuyên bố rằng tất cả các khối cũ hơn của nó đều không chính xác.

Người đặt cược tạo ra xác nhận cần đặt cược nó và những người đặt cược khác cũng có thể chọn đặt cược nó.

Nếu hai người đặt cược đặt cược vào sự khẳng định của chị em (anh chị em) và không có người đặt cược nào tham gia thử thách, thì hai người đặt cược có thể bắt đầu một thử thách trong đó người đặt cược trước đó hai chị em khẳng định đang bảo vệ tính đúng đắn của khẳng định chị gái trong khi người cam kết còn lại đang thách thức tính đúng đắn đó. Các bên liên quan thua cuộc thử thách sẽ mất quyền đặt cược và bị loại khỏi nhóm người đặt cược.

Thỏa thuận bao gồm thời hạn hành động. Đầu tiên, thời hạn để tạo xác nhận con của xác nhận cha là một giai đoạn thử thách sau khi xác nhận con đầu tiên được tạo. Thứ hai, thời hạn đặt cọc một xác nhận là khoảng thời gian thử thách sau khi xác nhận đó được tạo.

Nếu thời hạn đặt cược một xác nhận đã trôi qua và không có người đặt cược nào đặt cược xác nhận đó thì xác nhận đó sẽ bị xóa. Bất kỳ con, cháu hoặc con cháu nào khác của khẳng định bị cắt tỉa cũng bị cắt tỉa.

Nếu một xác nhận cũ hơn giai đoạn thử thách và không có xác nhận chị em nào chưa được cắt tỉa, thì xác nhận đó có thể được xác nhận, qua đó thể hiện sự tiến bộ trong giao thức.

Đánh giá

Giao thức có bằng chứng gian lận hợp lệ và không có nhà điều hành hoặc nhà cung cấp dịch vụ tập trung nào có thể chặn quá trình này, do đó, bất kỳ người tham gia có thể điều khiển quá trình. Để tiếp tục quá trình, người đặt cược trung thực có thể đưa ra xác nhận phụ chính xác nếu nó chưa tồn tại. Sau đó, một khoảng thời gian giới hạn sẽ trôi qua trước thời hạn để đảm bảo rằng không có thêm xác nhận chị em nào được tạo ra nữa và không có thêm người đặt cọc nào có thể đóng góp vào các xác nhận chị em hiện có. Kể từ thời điểm đó, những người đặt cược trung thực sẽ tham gia vào một loạt thử thách, lần lượt đánh bại và loại bỏ bên đặt cược sai (nếu có nhiều người tham gia đặt cược trung thực, họ có thể đánh bại đối thủ của mình cùng một lúc). Khi tất cả các bên này bị loại bỏ, xác nhận phụ chính xác có thể được xác nhận.

Cuộc tấn công trì hoãn hiệu quả nhất chống lại giao thức này là yêu cầu một người đặt cược độc hại cam kết một xác nhận chị em không chính xác và để N-1 người cam kết độc hại Người cam kết xác nhận chị em đúng . Cho dù có bao nhiêu người đặt cược trung thực đặt cược vào xác nhận chị em chính xác, kẻ tấn công có thể sắp xếp để người đặt cược không chính xác thách thức liên minh của mình trước khi bên trung thực có thể thách thức nó (một cách bi quan, điều này giả định rằng kẻ tấn công luôn có thể tham gia giao dịch trước bên trung thực ). Đồng minh cũng sẽ cố tình từ bỏ thử thách để trì hoãn càng lâu càng tốt (do quy định về độ trễ, mỗi đồng minh có thể cần một hoặc hai giai đoạn thử thách). Chỉ sau khi tất cả các đồng minh N-1 đã hy sinh bản thân, những người đặt cược sai sẽ được yêu cầu thách thức bên trung thực và bên trung thực sẽ giành chiến thắng, cuối cùng loại bỏ những người đặt cược sai.

Cuộc tấn công này đạt được độ trễ khoảng N giai đoạn thử thách với chi phí là N cổ phần.

Cái giá mà một bên trung thực phải trả cho cuộc tấn công này là tuyến tính theo số lượng các bên trung thực, vì mỗi bên trung thực cần phải đặt cược trước thời hạn đặt cược.

Tóm tắt:

Quy trình đảm bảo

Chi phí tấn công và độ trễ dẫn đến có liên quan tuyến tính

Chi phí của các bên trung thực có liên quan tuyến tính với số lượng các bên trung thực

Xác minh dựa trên quyền

Vấn đề với các cuộc tấn công bị trì hoãn mà Giao thức 2 được triển khai trên Arbitrum hiện đang gặp phải là chúng tôi đã chọn tạm thời giới hạn vai trò của người xác thực đối với một nhóm các bên được cấp phép, thay vì thực hiện việc xác thực hoàn toàn không được phép lý do. Bước cuối cùng để kích hoạt xác thực không cần cấp phép yêu cầu một phiên bản của giao thức có khả năng chống lại các cuộc tấn công độ trễ ở mức tối đa. Bạn có thể đoán rằng có một phiên bản của giao thức như vậy và chúng tôi hiện đang nỗ lực triển khai nó.

Giao thức 3 sắp tới

Bài viết này đã khá dài nên tôi sẽ không cung cấp mô tả cụ thể về giao thức mới, điều đó sẽ dành cho phần sau post Những điều sẽ được giới thiệu.

Để tóm tắt ngắn gọn các điểm chính: phiên bản tiếp theo của giao thức Arbitrum thực hiện một số thay đổi nhỏ nhưng (tôi nghĩ) tinh tế về cách thức hoạt động của các khẳng định và thách thức, Theo cách này, một cuộc tấn công trì hoãn trong trường hợp xấu nhất chỉ có thể gây ra sự chậm trễ trong một giai đoạn thử thách (bất kể kẻ tấn công sẵn sàng mất bao nhiêu cổ phần).

Điều này dựa trên bước đột phá về công nghệ của nhóm nghiên cứu Arbitrum giúp cho thách thức "tất cả chống lại tất cả" trở nên khả thi và hiệu quả. Điều này cho phép một người đặt cược trung thực có thể đánh bại một cách hiệu quả một nhóm lớn những kẻ tấn công đưa ra các xác nhận nhánh độc hại.

Các thông số kỹ thuật của giao thức mới đã được xác định đầy đủ và hiện đang được triển khai. Tất nhiên, chúng tôi sẽ không khởi chạy nó trên mạng chính cho đến khi mã được kiểm tra và xem xét kỹ lưỡng.

Trong một bài viết sau, tôi sẽ đi sâu vào giao thức mới này.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia