Kiến trúc

Tổng quan

FlareWatch là ứng dụng Next.js giám sát và theo dõi các vị trí trên Flare Network — staking, ủy quyền, phần thưởng và lợi suất. Đặc điểm kiến trúc xác định là nó chỉ đọc: không có cơ sở dữ liệu backend chứa trạng thái tài chính của người dùng, không có đường dẫn ký giao dịch, và không có quyền truy cập theo chương trình vào các khóa của người dùng. Tất cả dữ liệu vị trí được lấy từ cơ sở hạ tầng on-chain của Flare tại thời điểm yêu cầu.

Kết nối ví (Sign-In-With-Ethereum) chỉ tồn tại để xác định địa chỉ on-chain nào để truy vấn. Nó không được phép thực hiện các hành động on-chain vì ứng dụng không có hành động on-chain nào cần phép.

FlareWatch đọc cái gì và từ đâu

Mỗi địa chỉ hợp đồng được sử dụng bởi FlareWatch được phân giải lúc chạy từ FlareContractRegistry, sổ đăng ký địa chỉ on-chain chính tắc của Flare (0xaD67FE66660Fb8dFE9d6b1b4240d8650e30F6019). Khi quản trị Flare di chuyển một hợp đồng, FlareWatch lấy địa chỉ mới vào phiên tiếp theo mà không cần thay đổi mã.

Nguồn dữ liệu, theo thứ tự ưu tiên:

• On-chain (FlareContractRegistry, P-Chain RPC, C-Chain RPC, FTSOv2 Oracle) — nguồn sự thật cho số dư, stakes, phần thưởng có thể yêu cầu và giá cả.
• Flaremetrics API — siêu dữ liệu xác thực viên và nhà cung cấp FTSO quá tốn kém để tính toán phía máy khách.
• CoinGecko — dữ liệu giá nhiều tiền tệ và vốn hóa thị trường.
• Flare Block Explorer — tra cứu giao dịch lịch sử cho hồ sơ thuế và phân loại phần thưởng.

Luồng dữ liệu phân tầng

Ứng dụng thực thi quy tắc phân lớp một chiều nghiêm ngặt:

services → stores → hooks → components → pages

Hiệu ứng thực tế là tìm nạp, bắt nguồn và render đều có một nơi riêng. Một component cần dữ liệu validator sẽ đăng ký trạng thái validator — nó không bao giờ gọi API Flaremetrics trực tiếp.

Luồng phần thưởng

FlareWatch theo dõi bốn luồng phần thưởng độc lập. Coi bất kỳ luồng nào trong số này là một nhóm duy nhất sẽ gây ra sai số lợi suất đáng kể, đó là lý do tại sao mỗi luồng được lấy nguồn và tính toán riêng biệt.

Tiền gốc cổ phần P-Chain được trả về khi mở khóa và không phải là một luồng phần thưởng, mặc dù nó xuất hiện trong số dư tài khoản.

Ước tính lợi suất

FlareWatch sử dụng mô hình lợi suất ba cấp. Mỗi cấp được gắn nhãn trong UI để người dùng hiểu được độ chính xác của ước tính.

• Cấp 1 — Sự thật trực tiếp. Phần thưởng có thể yêu cầu trên chuỗi thông qua hợp đồng RewardManager. Đây là giá trị thực nằm trên chuỗi, chờ được yêu cầu.
• Cấp 2 — Hướng dẫn bởi dữ liệu. Khi số dư có thể yêu cầu bằng không, FlareWatch sử dụng trung vị của năm lần yêu cầu cuối cùng từ lịch sử giao dịch của ví làm ước tính cho chu kỳ tiếp theo.
• Cấp 3 — Dự phòng công thức. Khi không tồn tại lịch sử yêu cầu, wflrBalance × FTSO_DELEGATION_APR / epochsPerYear dự kiến tỷ lệ toán học từ trạng thái mạng hiện tại.

FlareWatch hiển thị một APY duy nhất cho staking Flare gốc và ủy thác FTSO: payout của epoch phần thưởng mới nhất trên mỗi FLR sau khi trừ phí, được tính hàng năm (× 365 / 3,5 ngày). Nó không được gộp lại, vì phần thưởng Flare phải được yêu cầu trước khi chúng có thể kiếm được, và nó khớp với con số mà các trình khám phá Flare khác công bố. Các vị trí DeFi tự động gộp lại (chẳng hạn như Sceptre sFLR) hiển thị APY giao thức riêng của họ.

Mô hình bảo mật — tóm lược

Bảo mật được đề cập chi tiết trên trang Tính năng bảo mật. Các điểm chính là:

• Nhận dạng dựa trên ví, không phải tài khoản. Không có mật khẩu, không có nhận dạng liên kết email. Kết nối ví xác định địa chỉ nào cần truy vấn.
• Chỉ đọc theo thiết kế. Ứng dụng không bao giờ lưu giữ khóa, không bao giờ ký giao dịch và không bao giờ tương tác với hợp đồng thông minh thay mặt người dùng.
• Thu hồi phiên trên máy chủ. Đăng xuất được thực thi trên máy chủ, vì vậy cookie phiên bị đánh cắp sẽ ngừng hoạt động ngay khi người dùng đăng xuất — không phải khi hết hạn 24 giờ.
• Xác thực quyền sở hữu ví từng cái. Mọi tuyến API đọc hoặc ghi trạng thái từng ví đều xác minh rằng ví được xác thực khớp với ví đích. Không có đường dẫn ghi đè quản trị viên nào cho dữ liệu người dùng.
• Tiêu đề HTTP phòng thủ đa lớp. Strict-Transport-Security, Content-Security-Policy hạn chế, X-Frame-Options DENY và Permissions-Policy chặt chẽ được gửi trên mọi phản hồi.

Kiểm thử

Ứng dụng được kiểm thử như thể mọi sai sót đều sẽ xảy ra — vì những loại sai sót mà FlareWatch quan tâm (các tính toán tài chính khác biệt tinh tế) im lặng khi được triển khai. Các lĩnh vực bảo phủ:

• Toán học APY staking và ủy thác FTSO.
• Định dạng tiền tệ trên nhiều khu vực pháp lý.
• Định dạng số lượng FLR, phần trăm và ngày.
• Logic dải màu ngưỡng (vì vậy một giao hàng "xanh" không bao giờ âm thầm chuyển sang màu hổphach).
• Tính toán thời hạn thuế trên nhiều khu vực pháp lý.

Bộ kiểm thử chạy trong CI trên mỗi lần đẩy.

Cơ sở hạ tầng

FlareWatch chạy trên Vercel. Frontend, các công việc cron làm nóng bộ đệm và kho khóa-giá trị được hỗ trợ bởi Redis giữ các bộ đệm đó đều chia sẻ nền tảng. Lựa chọn là cố ý: chi phí vận hành bằng không ở quy mô lớn và toàn bộ bề mặt triển khai có thể kiểm tra được thông qua một nhà cung cấp.

Lớp services/ được thiết kế độc lập với framework. Nếu FlareWatch bao giờ di chuyển ra khỏi Vercel, các dịch vụ logic kinh doanh là các hàm không đồng bộ thuần túy và di chuyển cùng nó.

Đọc thêm

• Các Tính Năng Bảo Mật — xác thực, ủy quyền, giới hạn tốc độ, tiêu đề, lịch sử kiểm toán.
• Tổng Quan Các Biện Pháp Bảo Vệ — các quy tắc kiến trúc mà FlareWatch áp dụng cho chính nó, và lý do tại sao.