FlareWatch

Tổng quan về Biện pháp Bảo vệ

FlareWatch duy trì một registry của các quy tắc kiến trúc — mỗi quy tắc là một lỗi cụ thể mà dự án không muốn lặp lại. Trang này giải thích hình dạng của registry và các danh mục mà nó bao gồm.

Cập nhật lần cuối May 2026

Registry là gì

Mỗi lớp lỗi lặp lại trong lịch sử FlareWatch đã được cô đọng thành một safeguard được đánh số: một quy tắc một đoạn, một sự chứng minh, và một con trỏ đến nơi trong mã mà nó được thực thi. Các safeguard mới được thêm khi một lớp lỗi hoặc mô hình xuất hiện và cần được ngăn chặn từ việc lặp lại.

Sổ đăng ký là một tài liệu đang hoạt động, không phải bản sao tiếp thị. Mục đích của nó là giữ cho nhóm — và vòng lặp đánh giá audit-first mà nhóm sử dụng — trung thực về những quy tắc nào áp dụng ở đâu. Sổ đăng ký được tham chiếu từ các bình luận mã nội tuyến (ví dụ: // Safeguard 24) để bất kỳ người đọc tệp nào cũng có thể tìm thấy quy tắc chi phối các dòng xung quanh.

Trang này là bản tóm tắt công khai. Sổ đăng ký đầy đủ nằm trong kho lưu trữ mã nguồn cùng với mã mà nó điều chỉnh. Mục đích ở đây là cung cấp cho một nhà nghiên cứu bảo mật, người xem xét cấp, hoặc một người đóng góp tiềm năng một ý tưởng về các danh mục mà sổ đăng ký bao gồm và loại kỷ luật mà nó thực thi.

Tại sao lại có registry

Một sổ đăng ký safeguard chỉ thực hiện mục đích của nó nếu nó ngăn chặn cùng một lỗi hai lần. Hồ sơ theo dõi của sổ đăng ký là câu trả lời:

  • Mỗi safeguard đặt tên cho lỗi mà nó ngăn chặn. Một quy tắc không có sự cố đã ghi nhớ phía sau nó không phải là một safeguard, đó là một tùy chọn phong cách. Tùy chọn phong cách thuộc về các quy tắc lint, không phải sổ đăng ký.
  • Safeguard được tham chiếu từ mã, không chỉ từ tài liệu. Một thay đổi mã vi phạm một safeguard được đọc như một cờ tại thời điểm xem xét vì số safeguard nằm trong các bình luận xung quanh.
  • Một số safeguard được thực thi tự động. Một tập hợp con được thực thi thông qua các quy tắc ESLint hoặc tập lệnh shell chạy trong CI. Phần còn lại dựa trên kỷ luật tác giả cộng với mô hình đánh giá audit-first, đã hoạt động tốt trong thực tế.
  • Sổ đăng ký được giữ trung thực bởi các bài kiểm tra. Một số safeguard được ghim bằng các bài kiểm tra hồi quy đọc các tệp mã nguồn dưới dạng chuỗi và khẳng định rằng các mô hình chống lại không xuất hiện. Tính giòn là tính năng: một tái cấu trúc trong tương lai quay trở lại một mô hình chống lại sẽ không vượt qua bài kiểm tra trước khi sự hồi quy tiến vào sản xuất.

Danh mục

Sổ đăng ký được sắp xếp theo miền. Các danh mục dưới đây là ổn định; các safeguard cụ thể trong mỗi danh mục được thêm khi các chế độ lỗi mới được phát hiện.

Danh mụcNhững gì nó bao gồm
Xác thực & ủy quyềnĐiểm nghẽn duy nhất để xác thực phiên, kiểm tra quyền sở hữu theo ví trên mọi tuyến đường, từ chối đa token giữa các token truy cập và làm mới, gating tuyến đường quản trị.
Tính toàn vẹn dữ liệuChuẩn hóa địa chỉ, hợp đồng chuyển đổi đơn vị tại các ranh giới sản xuất/tiêu dùng, kỷ luật xây dựng khóa, và các quy tắc chống hợp nhất im lặng các lỗi thành các giá trị không.
Các lần đọc trên chuỗiQuy tắc triển khai đơn cho bất kỳ giá trị nào được đọc từ hợp đồng thông minh, phân giải địa chỉ hợp đồng từ sổ đăng ký trên chuỗi và quy tắc chống trùng lặp logic phần thưởng.
Tính chính xác của màn hìnhĐịnh dạng số, tiền tệ và ngày tháng tập trung; bảo vệ giá trị null trên mọi hiển thị số; kỷ luật ghi nhãn APR so với APY; kỷ luật tỷ lệ thuế hiệu dụng.
Cảnh báo & thông báoNguồn sự thật duy nhất để đánh giá cảnh báo trên máy khách và máy chủ; danh sách cho phép rõ ràng cho các cảnh báo được phân tán tới các ví được theo dõi; quy tắc thay thế để cảnh báo "phần thưởng đã nhận" hủy cảnh báo cũ "phần thưởng có sẵn"; đồng bộ hóa tắt liên thiết bị.
Lưu trữ & bộ nhớ đệmQuy tắc cho khi kho lưu trữ chính tắc là phần phụ trợ cặp khóa-giá trị so với localStorage; kỷ luật di chuyển; bộ nhớ đệm service worker scoped triển khai; không dùng động rõ ràng cho các tuyến đọc trạng thái trực tiếp.
UI & vòng đờiCổng sẵn sàng trang, sàn đơn điệu ngăn không cho các số không tạm thời thay thế số dư đã biết và quy tắc hiển thị bộ xương trong cửa sổ tìm nạp lạnh.
Quy trình & công cụQuy tắc cho sự đồng ý khởi chạy tính năng rõ ràng, chạy bộ thử nghiệm đầy đủ trên các thay đổi bề mặt cảnh báo, ghi nhật ký có cấu trúc trong mã phía máy chủ và kỷ luật xem xét chống lại các bản sửa lỗi kiểu tắt.

Một số quy tắc tiêu biểu

Đây là những tóm tắt an toàn công cộng về các biện pháp bảo vệ minh họa đặc điểm của sổ đăng ký. Chúng được diễn đạt lại và rút gọn; văn bản chính thức nằm cạnh mã.

Nguồn sự thật duy nhất cho các lần đọc trên chuỗi

Bất kỳ giá trị nào được đọc từ hợp đồng thông minh — phần thưởng có thể yêu cầu, số dư, trạng thái stake, dữ liệu epoch, giá — được tính bằng chính xác một hàm trong lớp dịch vụ. Mọi tính năng cần giá trị đó đều nhập cùng một hàm. Nếu hai hàm tính toán giá trị giống nhau, một trong số chúng là sai; quy tắc là xóa nó, không phải thêm hàm thứ ba.

Điểm tắc nghẽn duy nhất để xác thực phiên

Mọi tuyến đường được xác thực trong FlareWatch đều xác thực cookie phiên thông qua một trợ giúp duy nhất. Không có trình xử lý tuyến đường nào xác minh mã thông báo phiên độc lập. Bất biến này chính là những gì làm cho việc thu hồi phía máy chủ trở nên phổ quát — không có cửa ngoài nào bỏ qua kiểm tra.

Gating quyền sở hữu theo ví, cả hai bên

Các tuyến đường theo ví xác minh quyền sở hữu phía máy chủ, không phải phía máy khách. Cuộc kiểm toán ban đầu thiết lập quy tắc này vì công việc trước đó đã đóng các cổng phía máy khách nhưng để các điểm cuối phía máy chủ hoàn toàn không bị gating. Hai nửa bây giờ được theo dõi dưới dạng các kết quả công việc rõ ràng riêng biệt — đóng trên máy khách, đóng trên máy chủ — để ngăn chặn chế độ lỗi đó tái diễn.

Sử dụng các trình định dạng tập trung, không bao giờ nội tuyến

Tất cả định dạng số, tiền tệ và ngày đều đi qua một tập hợp nhỏ các trợ giúp tập trung. Không có thành phần nào định dạng nội tuyến. Quy tắc này không liên quan gì đến kiểu dáng: khi một định nghĩa ngôn ngữ hoặc tiền tệ duy nhất thay đổi, mọi bề mặt trong ứng dụng sẽ cập nhật theo nó. Sự dịch chuyển giữa các bề mặt diễn ra âm thầm và khó phát hiện cho đến khi người dùng nhận thấy.

Chuyển đổi đơn vị được ghi lại ở cả hai đầu

Khi hai phần của hệ thống trao đổi các giá trị có đơn vị có thể gây nhầm lẫn (giây vs. mili giây, thập phân vs. phần trăm, chữ thường vs. địa chỉ có tính toán), quy ước sẽ được ghi lại ở cả nhà sản xuất và nhà tiêu dùng. Một bình luận chỉ ở một đầu sẽ lỗi thời; chỉ một hợp đồng ranh giới được khẳng định ở cả hai đầu mới có thể sống sót qua một lần tái cấu trúc.

Một triển khai cho mỗi hành động người dùng

Mọi hành động do người dùng khởi tạo — thêm ví được theo dõi, thay đổi tỷ lệ thuế, loại bỏ cảnh báo, đăng xuất — đều có chính xác một triển khai. Quy tắc này tồn tại vì các hành động được kích hoạt từ các phần khác nhau của giao diện người dùng thường xuyên dịch chuyển theo những cách tinh tế: một điểm vào sẽ xóa bộ nhớ đệm, điểm vào khác sẽ không, và một lớp các lỗi "giá trị cũ sau hoạt động X" sẽ xảy ra.

Các chế độ lỗi phải phát ra tiếng

Một số chế độ lỗi có bản chất âm thầm — một phần thưởng bị phân loại sai, một sự không khớp về đơn vị biến thông báo thành no-op, một bản ghi loại bỏ không bao giờ đến được kho khóa-giá trị. Khi có thể, sổ đăng ký yêu cầu các nhà sản xuất của các giá trị này khai báo hợp đồng của họ đủ lớn tiếng sao cho một thay đổi trong tương lai vi phạm nó thất bại ồn ào, trong các bài kiểm tra, trước khi đến thâm phủ.

Cách sổ đăng ký phát triển

  • Các biện pháp bảo vệ mới. Được thêm vào khi một lớp lỗi tái diễn hoặc một lỗi duy nhất đã tốn kém đủ để biện minh cho một quy tắc vĩnh viễn.
  • Các biện pháp bảo vệ bị thay thế. Được giữ trong sổ đăng ký với dấu "superseded" và con trỏ đến phần thay thế, để các tham chiếu lịch sử trong mã vẫn có thể diễn giải được.
  • Được nâng cao từ các ghi chú làm việc. Một số biện pháp bảo vệ bắt đầu như các quy tắc không chính thức trong tài liệu bàn giao phiên làm việc và được nâng cao lên sổ đăng ký sau khi chúng đã chứng minh được trọng lượng của chúng.
  • Quét hàng quý. Các ngoại lệ lint tạm thời và các dấu "cần hoàn thành trong quý tới" được kiểm tra theo từng quý. Bất cứ điều gì đã vượt quá thời hạn sẽ được giải quyết hoặc được gia hạn rõ ràng.

Tại sao được công bố

FlareWatch công bố tổng quan này, thay vì toàn bộ sổ đăng ký nội bộ, vì hai lý do.

  • Sổ đăng ký nội bộ chứa chi tiết cấp độ mã (đường dẫn tệp, tên lược đồ khóa-giá trị, dấu thời gian sự cố) hữu ích cho nhóm và những người đánh giá bảo mật có quyền truy cập mã, nhưng không thích hợp để công bố mà không có quyền truy cập đó.
  • Các danh mục và kỷ luật là câu chuyện thực tế. Một người đánh giá hỗ trợ hoặc nhà nghiên cứu bảo mật đánh giá FlareWatch muốn biết dự án loại nào, nó coi trọng độ chính xác như thế nào, và vòng làm việc của nó trông như thế nào — không phải tệp nào chứa quy tắc số 91.

Các nhà nghiên cứu muốn thảo luận về một biện pháp bảo vệ cụ thể, đề xuất một biện pháp mới, hoặc báo cáo một khoảng trống được chào đón liên hệ tại [email protected].

Đọc thêm

FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.