Tôi có một người anh em làm mô hình tính toán định giá trong một công ty bảo hiểm. Công việc hằng ngày của anh ấy là định giá rủi ro thảm họa. Tôi kể cho anh ấy nghe logic tịch thu/phạt mà tôi dùng, mang con số @BabylonLabs_io , và muốn anh ấy cho tôi một góc nhìn từ xác suất: ví dụ như nếu làm kiểm chứng node trong một năm bị tịch thu/phạt thì xác suất đó ở mức độ cỡ nào?
Nghe xong anh ấy không trả lời ngay, mà hỏi ngược lại rằng các bạn dùng phân phối xác suất nào cho sự kiện tịch thu/phạt này — Poisson hay Weibull? Các bạn có kiểm tra đặc tính đuôi dày (thick tail) chưa? Tôi bị hỏi tới mức bí.
Anh ấy nói trong lĩnh vực tài chính-bảo hiểm, để định giá bất kỳ một sự kiện rủi ro nào thì trước hết phải xác định được loại phân phối của nó; sau đó mới hiệu chỉnh tham số dựa trên tần suất lịch sử. Nhưng sự kiện tịch thu/phạt trong giới crypto của các bạn thì lại có hai vấn đề: (1) không có chuỗi dữ liệu thời gian đủ dài để đo; (2) các lần kích hoạt tịch thu/phạt thường không phải là các sự kiện ngẫu nhiên độc lập. Lỗi bug của phần mềm node, tắc nghẽn mạng Bitcoin, độ trễ timestamp… đều có mức độ tương quan cao; trong trường hợp cực đoan, chúng có thể bùng phát dồn dập thành cụm.
Anh ấy gọi loại rủi ro này trong tính toán bảo hiểm là “rủi ro chưa được mô hình hóa đầy đủ” (under-modeling risk). Điều nguy hiểm nhất không phải là xác suất cao, mà là bản thân xác suất đó còn không chắc chắn, không đúng. Các công ty bảo hiểm gặp loại rủi ro này thường sẽ từ chối bảo hiểm hoặc gắn một mức phí bảo hiểm trên trời, vì sự bất định chính là chi phí lớn nhất. Trên Babylon, các validator hiện đang giống như chạy trần rủi ro tịch thu/phạt này mà không có mô hình tính toán bảo hiểm; mọi người nghĩ là không sao không phải vì rủi ro thấp, mà vì mẫu quá nhỏ nên chưa đụng phải.
#baby $BABY
Nghe xong anh ấy không trả lời ngay, mà hỏi ngược lại rằng các bạn dùng phân phối xác suất nào cho sự kiện tịch thu/phạt này — Poisson hay Weibull? Các bạn có kiểm tra đặc tính đuôi dày (thick tail) chưa? Tôi bị hỏi tới mức bí.
Anh ấy nói trong lĩnh vực tài chính-bảo hiểm, để định giá bất kỳ một sự kiện rủi ro nào thì trước hết phải xác định được loại phân phối của nó; sau đó mới hiệu chỉnh tham số dựa trên tần suất lịch sử. Nhưng sự kiện tịch thu/phạt trong giới crypto của các bạn thì lại có hai vấn đề: (1) không có chuỗi dữ liệu thời gian đủ dài để đo; (2) các lần kích hoạt tịch thu/phạt thường không phải là các sự kiện ngẫu nhiên độc lập. Lỗi bug của phần mềm node, tắc nghẽn mạng Bitcoin, độ trễ timestamp… đều có mức độ tương quan cao; trong trường hợp cực đoan, chúng có thể bùng phát dồn dập thành cụm.
Anh ấy gọi loại rủi ro này trong tính toán bảo hiểm là “rủi ro chưa được mô hình hóa đầy đủ” (under-modeling risk). Điều nguy hiểm nhất không phải là xác suất cao, mà là bản thân xác suất đó còn không chắc chắn, không đúng. Các công ty bảo hiểm gặp loại rủi ro này thường sẽ từ chối bảo hiểm hoặc gắn một mức phí bảo hiểm trên trời, vì sự bất định chính là chi phí lớn nhất. Trên Babylon, các validator hiện đang giống như chạy trần rủi ro tịch thu/phạt này mà không có mô hình tính toán bảo hiểm; mọi người nghĩ là không sao không phải vì rủi ro thấp, mà vì mẫu quá nhỏ nên chưa đụng phải.
#baby $BABY