1. Bối cảnh
Là một nhà phát triển, không học hỏi đồng nghĩa với việc chúng ta bị bỏ lại phía sau. Đôi khi nó đã được kể từ khi Ethereum & Solidity được giới thiệu. Sau đó, chúng ta có nhiều định nghĩa mới như DeFi, NFT, DApps, v.v. Hôm nay, hãy nói về việc bảo mật DApp của bạn.
2. Sự cân nhắc
Vì vậy, bạn đã bao giờ tự hỏi làm thế nào để xác nhận kết quả giao dịch bằng các phương pháp hay nhất? Cùng đi sâu tìm hiểu ngay nhé!
3. Ví dụ
Giả sử công ty của bạn là công ty phát triển Trò chơi. Để hỗ trợ công việc kinh doanh, công ty của bạn yêu cầu bạn phát triển một ứng dụng bỏ phiếu cộng đồng phi tập trung cho ý tưởng phát triển tiếp theo.
Yêu cầu ứng dụng đơn giản như sau:
- Ứng dụng phải chạy trong hợp đồng thông minh chuỗi khối Ethereum
- Người dùng có thể xem phiếu bầu hiện tại trong trang bỏ phiếu
Trang chỉ đơn giản như vậy:
4. Các cách tiếp cận khác nhau
4.1 Cách tiếp cận Web3 hoàn toàn
Trong thiết kế này, chúng tôi sẽ lưu trữ tất cả dữ liệu phiếu bầu cần thiết cho hợp đồng thông minh. Và khi hiển thị dữ liệu lên Frontend, chúng tôi sẽ gọi trực tiếp hợp đồng thông minh cho dữ liệu bạn cần. Đó có thể là cách tiếp cận đơn giản nhất vì chúng ta chỉ cần 2 lớp với Frontend & Blockchain.
Tuy nhiên, thiết kế này không lý tưởng cho việc mở rộng quy mô. Hầu hết các nhà cung cấp RPC đều có giới hạn gas trên eth_call . Vì vậy, khi dữ liệu được lưu trữ trong hợp đồng của bạn trở nên quá lớn. Không thể truy vấn từ giao diện người dùng của khách hàng.
4.2 Cách tiếp cận Web 2.5
Và vâng. Mọi thứ đều có cách giải quyết của riêng nó. Chúng tôi có thể giải quyết mối quan tâm mở rộng quy mô bằng Backend & A DB tập trung bổ sung như thế này.
Khi chúng tôi hiển thị dữ liệu trong FE, Chúng tôi sẽ không truy vấn Blockchain nữa. Thay vào đó, chúng tôi truy vấn Backend & DB tập trung. Điều đó nhanh hơn nhiều và chúng tôi sẽ có nhiều quyền kiểm soát hơn với dữ liệu (có nghĩa là tập trung hơn)
Mọi thứ trở nên phức tạp hơn một chút khi chúng tôi thêm máy chủ Phụ trợ này. Và chúng ta nên có những mối quan tâm sau
Mối quan tâm 1: Làm thế nào để đối phó với thời gian xử lý giao dịch
Hãy xem lại Ví dụ 1 sau đây:
- Người dùng kết nối ví của họ trong Frontend
- Người dùng thực hiện giao dịch bỏ phiếu thông qua ví của họ
- Sau khi giao dịch hoàn tất trong Blockchain, chúng tôi sẽ gọi một API phụ trợ để lưu thông tin giao dịch vào DB tập trung
Thiết kế này sẽ hoạt động, nhưng đôi khi nó sẽ thất bại . Vì giao dịch bỏ phiếu được thực hiện bằng Blockchain nên sẽ mất một khoảng thời gian để được xác nhận hoàn toàn. Khi giao dịch không được xác nhận hoàn toàn, người dùng bằng cách nào đó sẽ đóng Trình duyệt hoặc Ứng dụng giao diện người dùng của họ. Nó có nghĩa là nó kết thúc mà không có bước 3 và dữ liệu sẽ không được lưu vào DB tập trung mặc dù giao dịch được thực hiện bằng blockchain.
=> Tất nhiên, chúng ta có thể giải quyết nó bằng cách thay đổi quy trình một chút với Ví dụ 2 sau:
- Người dùng kết nối ví của họ trong Frontend
- Người dùng thực hiện giao dịch bỏ phiếu thông qua ví của họ
- Ngay sau khi người dùng ký giao dịch bằng ví của họ, chúng tôi gọi API để lưu băm giao dịch đã tạo vào DB tập trung
- Định cấu hình cron-job để kết nối với chuỗi khối để truy vấn chuỗi khối về thông tin giao dịch và rút gọn dữ liệu cần thiết để lưu vào DB
Giải pháp này tốt hơn nhiều vì chúng tôi đã lưu băm giao dịch ngay sau khi người dùng ký giao dịch. Nhưng cách này sẽ khiến chúng ta thêm lo ngại.
Mối quan tâm 2: Cách xác thực dữ liệu đến từ Giao diện người dùng
Chúng ta sẽ đi sâu vào bước 3 trong Ví dụ 2 . Trong bước này, chúng tôi cho phép người dùng cập nhật transaction_hash của họ bằng API của chúng tôi. Nó có thể trở thành một điểm dễ bị tấn công nếu chúng tôi không xác thực thông tin này một cách chặt chẽ. Hãy để tôi đề cập đến một số cuộc tấn công có thể xảy ra ở đây:
① Cuộc tấn công bất khả thi 1: Một số kẻ spam sẽ gọi api này nhiều lần với cùng một băm giao dịch
② Cuộc tấn công bất khả thi 2: Một số kẻ spam sẽ thực hiện một hợp đồng tương tự và thực hiện giao dịch với hợp đồng của chính họ và cập nhật mã băm giao dịch đó vào DB của chúng tôi. Nó có nghĩa là, dữ liệu Bầu chọn sẽ trở nên không đáng tin cậy với dữ liệu sai.
Có thể dễ dàng ngăn chặn bằng cách kiểm tra trùng lặp trong API. Nhưng ② không thể. ② Tại thời điểm gọi API này, rất có thể giao dịch chưa có sẵn trong Blockchain. Vì vậy, chúng tôi không thể ngăn chặn ② trong xác thực API.
=> Vì ② không thể được xác thực khi giao dịch không có sẵn trong Blockchain. Vì vậy, hãy xác thực nó khi nó có sẵn trong Blockchain. Chúng tôi có thể xác nhận nó trong cron-job của chúng tôi khi chúng tôi kiểm tra kết quả giao dịch.
Tuy nhiên, nó vẫn chưa hoàn hảo. Trong Thiết kế này, nếu người dùng chuyển một mã băm giao dịch không hợp lệ, nó sẽ không được xác thực bởi cron-job của chúng tôi nhưng có một cách khác không cho phép người dùng cập nhật mã băm giao dịch của riêng họ trong giao diện người dùng.
Giải pháp khả thi 1
Để có giải pháp tốt hơn, chúng ta nên thiết kế như sau:
- Người dùng kết nối ví của họ trong Frontend
- Backend tạo một id duy nhất, lưu nó vào DB và đưa nó vào giao diện người dùng
- Người dùng thực hiện giao dịch bỏ phiếu thông qua ví của họ với id duy nhất được tạo
- Ngay sau khi người dùng ký giao dịch bằng ví của họ, chúng tôi gọi API để yêu cầu cron-job trực tiếp truy vấn blockchain để tìm id duy nhất trong hợp đồng đích cho thông tin giao dịch.
Bằng cách này, người dùng sẽ không còn khả năng cập nhật nhầm transaction_hash nữa, chúng tôi truy vấn trực tiếp chuỗi khối để có dữ liệu đáng tin cậy nhất.
Giải pháp khả thi 2
Chúng tôi cũng có thể sử dụng Dịch vụ lập chỉ mục chuỗi khối như Đồ thị để giải quyết tất cả vấn đề.
Trong Thiết kế này, chúng tôi thay thế lớp Phụ trợ của chúng tôi bằng Biểu đồ. Biểu đồ sẽ giúp chúng tôi lập chỉ mục dữ liệu blockchain để chúng tôi truy vấn nó một cách hiệu quả. Nó có thể được coi là Giải pháp Web3 đầy đủ với khả năng mở rộng tốt. Nhưng chúng ta nên cân nhắc về giá cả của dịch vụ. Chúng tôi phải sử dụng mã thông báo của nó có tên là GRT để trả phí truy vấn. Mã thông báo GRT chỉ là
5. Kết luận
Hãy chia sẻ giải pháp của bạn & Mã hóa vui vẻ ~~