Cách giải quyết lỗ hổng chạy trước trong hợp đồng thông minh

Ngay cả khi việc xếp hàng ở siêu thị hoặc tại các cửa hàng nơi bạn thanh toán hóa đơn tiện ích đã là lịch sử, thì một số người trong chúng ta vẫn biết cảm giác khi ai đó nhảy vào xếp hàng.

Ở phía trước của hàng đợi, đó là. Đặc biệt, nếu vì lý do hóa đơn của họ có giá trị cao hơn nhiều so với những người khác đang xếp hàng. Rõ ràng, đây không phải là một tiêu chí khi nói đến sự nhanh chóng của dịch vụ.

Giờ đây, hoạt động kinh doanh được chuyển lên hàng đầu này cũng xảy ra trong các hợp đồng thông minh Ethereum. Còn được gọi là lỗi chạy trước, có tên được lấy từ một hiện tượng tương tự của thị trường chứng khoán, các giao dịch hợp đồng thông minh trả phí gas cao hơn có xu hướng được ưa chuộng hơn những giao dịch không trả.

Phá vỡ lỗ hổng Front-running

Ngay lập tức, lỗ hổng này không xảy ra do lập trình bị lỗi mà sử dụng cách các giao dịch được sắp xếp và thêm vào một khối từ 'mempool'.

Ngoài những người dùng thông thường muốn kiếm tiền nhanh chóng, những người khai thác có xu hướng kiếm lợi từ một giao dịch như vậy và đó là lý do tại sao họ là những người có nhiều khả năng theo dõi các giao dịch đó trước khi chúng được thêm vào một khối. Trên thực tế, một khi họ làm như vậy, họ sẽ gửi một giao dịch của riêng mình để nhận phần thưởng tài chính không công bằng, giao dịch này cuối cùng sẽ được thêm vào một khối thay vì khối được gửi trước.

Điều cần lưu ý ở đây là các giao dịch đã được cam kết với giá xăng cao hơn có xu hướng được xử lý trước so với các giao dịch khác. Lưu ý đến sở thích này, kẻ tấn công có thể thay đổi kết quả của các sự kiện như đấu giá, giao dịch hoặc cung cấp tiền xu ban đầu theo hướng có lợi cho chúng chỉ bằng cách trả phí gas cao hơn.

Hãy xem ví dụ phổ biến này để hiểu cách thức hoạt động của lỗ hổng frontrunning:

Trong ví dụ này, chúng ta có ba diễn viên: Naman, Kaavya và Aishwarya. Đầu tiên, Naman triển khai thử thách Băm như một hợp đồng thông minh để hai người kia giải quyết. Bất cứ ai giải được câu đố băm này sẽ nhận được phần thưởng là 10 ether.

Bây giờ, Kaavya tìm giải pháp băm trước và gửi nó với 10 Gwei dưới dạng phí gas, từ hợp đồng thông minh của chính cô ấy:

Mặt khác, Aishwarya tìm thấy câu trả lời muộn hơn một chút và chuyển câu trả lời đúng cho hợp đồng thông minh của cô ấy với 100 Gwei dưới dạng phí gas.

Vì trả phí gas cao hơn, thay vì Kaavya nhận được phần thưởng 10 Ether, Aishwarya nhận được nó, như hình bên dưới:

Nói một cách đơn giản, đây là lỗi chạy trước hoặc lỗi đặt hàng giao dịch, vì nó xử lý các giao dịch dựa trên giá trị của phí gas.

Nói cách khác, ngay cả khi Kaavya gửi câu trả lời của mình trước Aishwarya, cô ấy không nhận được gì cho những nỗ lực của mình, như hình dưới đây:

Vì 'nhảy vào hàng' này của Aishwarya sẽ không phù hợp với Kaavya hoặc bất kỳ ai khác, một số biện pháp phòng ngừa phải được xem xét cho mã hợp đồng thông minh của chúng tôi.

3 cách để đối phó với lỗ hổng Frontrunning

Bây giờ, có những bản sửa lỗi có thể ngăn chặn sự mất mát như vậy. Nói cách khác, chúng tôi sẽ có thể khóa một giao dịch là giao dịch sẽ nhận được 10 Ether.

Cách 1: Quầy giao dịch

Sử dụng quầy giao dịch là một trong những cách đơn giản nhất để ngăn chặn bất kỳ ai khác nhận phần thưởng bằng bất kỳ phương tiện nào khác.

Như bạn có thể biết từ đoạn mã được thêm bên dưới, một bộ đếm giao dịch đã được thêm vào để khóa giao dịch được cam kết bởi người đã hoàn thành thử thách băm trước. Vì chỉ người đầu tiên làm như vậy mới nhận được phần thưởng, chúng tôi thông báo cho tất cả những người tham gia thêm giá trị 0 cùng với giải pháp của họ.

Vì giá trị hiện tại của txCounter sẽ bằng 0 đối với giải pháp được trình bày đầu tiên, nên nó sẽ bị khóa. Nói cách khác, và như trong ví dụ trên, Kaavya sẽ nhập giải pháp của cô ấy cũng như giá trị bằng 0 để nhận phần thưởng là 10 Ether .

Nếu bất kỳ ai khác làm điều này, giải pháp sẽ không được chấp nhận vì bộ đếm giao dịch đã được tăng lên một giá trị lớn hơn một. Vào thời điểm đó, toàn bộ phần thưởng 10 Ether đáng lẽ sẽ được trao cho Kaavya, sẽ được chuyển ngay cho cô ấy.

Phương pháp 2: Đặt giới hạn Gas

Giờ đây, với phương pháp này, trọng tâm là đặt giới hạn gas cho tất cả các giao dịch. Cả hai, giới hạn trên và dưới, nếu cần.

Như bạn có thể nhớ lại, các giao dịch được sắp xếp dựa trên số tiền phí gas đã được thanh toán cho giao dịch nói trên. Mặc dù điều này có thể không loại bỏ hoàn toàn thứ tự đó, nhưng điều này chắc chắn sẽ làm giảm nó ở một mức độ lớn.

Nếu bạn nhìn vào mã bên dưới, tất cả các giao dịch trả gas với số lượng từ 1 trở xuống sẽ được thực hiện nhưng những người cố gắng vượt qua giới hạn bằng cách trả nhiều gas hơn sẽ không, nhờ công cụ sửa đổi gasThrottle. Trong trường hợp này, 1 Wei hoặc Gwei có thể là chi phí tiêu chuẩn để xử lý một giao dịch như vậy và đó là tất cả những gì sẽ được phép.

Vì vậy, nếu tất cả các giao dịch không thay đổi nhiều như vậy về gas nhờ điều tiết này, thì vấn đề thể hiện sự ưu tiên đối với một số giao dịch nhất định sẽ không phát sinh. Mặc dù có những lợi thế đối với cách tiếp cận như vậy, nhưng phí xăng phải trả chắc chắn sẽ thay đổi trong tương lai.

Mức cao hôm nay sẽ thấp trong một vài năm tới, vì vậy Naman phải luôn cảnh giác với điều này. Hoặc nếu không, Aish có thể tận dụng lợi thế của những giá trị thay đổi này chỉ bằng cách đợi một lúc.

Phương pháp 3: Phương pháp gửi tàu ngầm

Giờ đây, mặc dù hai cách tiếp cận trước đây có thể hoạt động đối với các tình huống đơn giản hơn, nhưng chúng không bao giờ thực sự giải quyết được nguyên nhân gốc rễ của lỗ hổng chạy trước: tiết lộ đầy đủ thông tin giao dịch cho cả người khai thác và người dùng độc hại khác.

Rõ ràng là miễn là hai bên này có quyền truy cập vào thông tin của từng giao dịch, thì cơ hội chơi trò chơi của hệ thống vẫn còn. Rõ ràng, một phương pháp mà thông tin nhạy cảm với thời gian này phải được ẩn đi là cần thiết và đưa chúng ta đến phương pháp gửi tàu ngầm, được triển khai như một phần của thư viện hợp đồng thông minh LibSubmarine .

Khi một người sử dụng phương pháp này, họ sẽ ẩn thông tin giao dịch theo cách mà những người khai thác hoặc người dùng thông thường thực sự không thể tận dụng được. Mã hóa đóng một vai trò lớn trong việc bảo vệ thông tin này, dựa trên quyết định của chủ sở hữu, có thể được tiết lộ sau khi được thêm vào một khối.

Điều đó nói rằng, ngay cả khi phương pháp này không hoàn hảo, thì mức độ bảo vệ mà nó mang lại vẫn tốt hơn nhiều so với các phương pháp khác, vì nó sẵn sàng giải quyết lý do thực sự tại sao chạy trước lại diễn ra — cả trong thế giới thực và trên chuỗi khối.

Các chiến lược khác để vượt qua lỗ hổng Frontrunning

Tất nhiên, các chiến lược được thảo luận trong phần trước không phải là những chiến lược duy nhất bảo vệ các hợp đồng thông minh khỏi lỗ hổng 'chạy trước'.

Với chuỗi bên, việc đặt hàng diễn ra ngoài chuỗi trong khi việc thanh toán diễn ra trên đó. Với hai bước này diễn ra trên các nền tảng khác nhau, điều này không chỉ mang lại lợi ích cho việc tăng thông lượng mà còn ngăn cản những người khai thác hoặc người dùng thông thường lấy thông tin cần thiết để khai thác lỗ hổng chạy trước.

Một chiến lược khác, ngay cả khi về bản chất là lý thuyết, liên quan đến việc ngẫu nhiên hóa thứ tự giao dịch cho một vòng cụ thể đã được cam kết trong sơ đồ tiết lộ cam kết. Điều này được thi hành bằng logic hợp đồng thông minh. Những người đi trước sẽ không đứng đầu hàng với cách tiếp cận này vì thứ tự được xác định bởi hợp đồng thông minh đã nói ở trên.

Cuối cùng, một cách tiếp cận khác liên quan đến việc triển khai Giao thức Injective nơi người dùng giải quyết các chức năng trì hoãn có thể kiểm chứng cho giá trị t cực kỳ quan trọng đó để xác định ai nhận được đơn đặt hàng. Do đó, bằng cách có thể loại bỏ hệ thống sắp xếp ngẫu nhiên mà hầu hết các chuỗi khối sử dụng, khả năng xảy ra các cuộc tấn công từ phía trước cũng giảm đi.