Thiết kế của Price Feed đã khiến 60 triệu USD trở thành một thảm họa trị giá 19 tỷ USD

Ngày 10-11 tháng 10 năm 2025, một đợt bán tháo 60 triệu USD đã cuốn phăng 19,3 tỷ USD giá trị thị trường. Không phải từ việc sụp đổ thị trường. Không phải do các cuộc gọi ký quỹ dây chuyền đối với các vị thế thực sự bị thiệt hại. Mà do lỗi hệ thống oracle.

Đây không phải là điều mới. Mô hình tấn công này đã được khai thác thành công từ tháng 2 năm 2020, gây thiệt hại hàng trăm triệu USD cho ngành qua hàng chục sự kiện. Tháng 10 năm 2025 khuếch đại gấp 160 lần vụ tấn công oracle lớn nhất trước đó—không nhờ kỹ thuật tinh vi, mà bởi hệ thống mở rộng quy mô nhưng vẫn giữ nguyên lỗ hổng cốt lõi.

Năm năm bài học đắt giá đã bị phớt lờ. Bài phân tích này lý giải nguyên nhân.

Bài toán Oracle: Độ nhạy hay ổn định?

Mỗi nền tảng giao dịch ký quỹ đều đối mặt với một bài toán cốt lõi: Làm sao định giá tài sản thế chấp chính xác mà vẫn ngăn chặn thao túng?

Quá nhạy → dễ bị thao túng Quá ổn định → bỏ qua tổn thất thực sự

Tháng 10 năm 2025 lựa chọn độ nhạy. Oracle liên tục ghi nhận giá giao ngay khi 60 triệu USD bị bán tháo, định giá lại tài sản thế chấp theo thời gian thực, kích hoạt thanh lý hàng loạt. Hệ thống vận hành đúng thiết kế.

Nhưng thiết kế này sai nghiêm trọng.

Mô hình năm năm chúng ta đã bỏ qua

Trước khi phân tích sự kiện tháng 10 năm 2025, cần hiểu: chúng ta từng ở đây.

Kịch bản (2020-2022)

Tháng 2 năm 2020: bZx (350.000 USD + 630.000 USD) Oracle đơn nguồn. Thao túng giá WBTC trên Uniswap bằng flash loan. 14,6% tổng cung dịch chuyển để thao túng nguồn dữ liệu duy nhất mà bZx dựa vào.

Tháng 10 năm 2020: Harvest Finance (24 triệu USD bị đánh cắp, 570 triệu USD rút tiền hàng loạt) Bảy phút. Flash loan 50 triệu USD. Thao túng giá stablecoin trên Curve. Kích hoạt sụp đổ hạ tầng và rút thanh khoản lớn hơn cả số tiền bị đánh cắp.

Tháng 11 năm 2020: Compound (89 triệu USD bị thanh lý) DAI tăng lên 1,30 USD trên Coinbase Pro—không ở đâu khác. Oracle của Compound dùng Coinbase làm chuẩn. Người dùng bị thanh lý dựa trên giá chỉ tồn tại trên một sàn trong một giờ. Chỉ cần 100.000 USD thao túng sổ lệnh với độ sâu 300.000.

Tháng 10 năm 2022: Mango Markets (117 triệu USD) Vốn ban đầu 5 triệu USD. Đẩy giá MNGO tăng 2.394% trên nhiều sàn. Vay 117 triệu USD dựa trên tài sản thế chấp bị thổi phồng. Dùng token quản trị bị đánh cắp để tự bỏ phiếu nhận “bug bounty” 47 triệu USD. CFTC lần đầu tiên xử lý hành vi thao túng oracle.

Mẫu số chung

Mọi vụ tấn công đều theo logic giống nhau:

1. Xác định oracle phụ thuộc nguồn dễ thao túng
2. Tính toán: Chi phí thao túng < Giá trị có thể khai thác
3. Thực hiện
4. Thu lợi

Từ 2020-2022: 403,2 triệu USD bị đánh cắp qua 41 vụ thao túng oracle.

Phản ứng ngành: Rời rạc, chậm và không đầy đủ. Đa số nền tảng vẫn dùng oracle thiên về giá giao ngay, thiếu dự phòng.

Và rồi tháng 10 năm 2025 xuất hiện.

Giải phẫu thất bại Oracle: Phiên bản 2025

Ngày 10 tháng 10 năm 2025, 05:43: 60 triệu USD USDe bị bán tháo trên thị trường giao ngay.

Với oracle thiết kế chuẩn: Tác động tối thiểu, được hấp thụ bởi nhiều nguồn độc lập.

Nhưng với oracle này: Thảm họa xảy ra.

Bán tháo 60 triệu USD → Oracle giảm giá tài sản thế chấp (wBETH, BNSOL, USDe) →

Thanh lý hàng loạt → Quá tải hạ tầng → Hụt thanh khoản → 19,3 tỷ USD bị xóa sổ

Hệ số khuếch đại

• Mango Markets (2022): Thao túng 5 triệu USD → Rút 117 triệu USD (gấp 23 lần)
• Tháng 10 năm 2025: Thao túng 60 triệu USD → Hủy hoại 19,3 tỷ USD (gấp 322 lần)

Không phải vì kỹ thuật phức tạp. Mà do lỗ hổng vẫn tồn tại ở quy mô tổ chức.

Bài toán phân bổ trọng số

Oracle quá phụ thuộc vào giá giao ngay từ sàn chính. Khi một sàn chiếm ưu thế về khối lượng:

• Khối lượng lớn cho thấy khám phá giá diễn ra ở đó (có vẻ hợp lý)
• Nhưng tập trung tạo lỗ hổng thao túng (gây chết người)
• Dùng giá nội bộ duy nhất tạo vòng lặp tự tham chiếu (làm vấn đề nghiêm trọng hơn)

Một chuyên gia nhận xét: “vì [sàn giao dịch đó] có khối lượng lớn nhất cho usde/bnsol/wbeth, nên dù theo trọng số oracle vẫn nên lấy theo giá giao ngay.”

Trực giác này—tin vào thị trường lớn nhất—đã khiến hàng tỷ USD bị thổi bay qua năm năm các vụ tấn công oracle. Tập trung khối lượng không chứng minh độ chính xác giá. Đó là dấu hiệu cho cơ hội thao túng.

Cửa sổ lỗ hổng dự kiến

Phương pháp oracle mới được thông báo tám ngày trước khi áp dụng. Kẻ tấn công có:

• Biết rõ các phụ thuộc oracle
• Biết thời gian chuyển đổi
• Tám ngày để chuẩn bị và bố trí vị thế

Các vụ tấn công trước khai thác lỗ hổng sẵn có. Tháng 10 năm 2025 khai thác lỗ hổng trong quá trình chuyển đổi phương pháp oracle—chỉ xuất hiện vì cải tiến được công bố trước khi thực thi.

Kiểm thử cô lập địa điểm giao dịch

Bằng chứng rõ nhất đây là thất bại oracle, không phải tài sản bị hủy hoại:

Sàn chính: USDe ở mức 0,6567 USD, wBETH ở mức 430 USD Sàn khác: chênh lệch dưới 30 điểm cơ bản

Pool on-chain: Tác động tối thiểu

Guy từ Ethena nhận định: “hơn 9 tỷ USD tài sản thế chấp stablecoin có thể quy đổi ngay lập tức” xuyên suốt sự kiện.

Giá biến động mạnh chỉ trên sàn nguồn của oracle, còn ở nơi khác vẫn ổn định. Oracle ghi nhận mức giá thao túng. Hệ thống tiến hành thanh lý dựa trên giá không tồn tại ở thị trường.

Đây chính là mô hình Compound 2020: thao túng tại một điểm, oracle ghi nhận chính xác, hệ thống bị phá hủy hàng loạt.

Hiệu ứng dây chuyền hạ tầng

Chuyên gia agintender chỉ ra cơ chế khuếch đại:

“Thanh lý dây chuyền khiến máy chủ quá tải với hàng triệu lượt yêu cầu. Market makers không thể đặt giá kịp thời, tạo ra khoảng trống thanh khoản.”

Đây là mô hình Harvest Finance mở rộng quy mô. Kẻ tấn công kích hoạt thanh lý nhanh hơn hạ tầng xử lý. Market makers không phản ứng kịp. Thanh khoản biến mất. Hiệu ứng dây chuyền tự củng cố.

Sau khi Harvest sụp đổ hạ tầng tháng 10 năm 2020 (TVL giảm từ 1 tỷ USD xuống 599 triệu USD), bài học đã quá rõ: hệ thống oracle phải tính đến năng lực hạ tầng khi xảy ra sự kiện căng thẳng.

Tháng 10 năm 2025 đã chứng minh ta chưa học được điều đó.

Cân bằng độ nhạy: Hai phương án, một thảm họa

Guy từ Ethena đã nêu rõ thách thức thiết kế: Oracle phải phân biệt biến động tạm thời (nhiễu thị trường) và tổn thất thực sự (mất mát thật).

Tháng 10 năm 2025 cho thấy hai phản ứng:

Phương án độ nhạy cao (Sàn thất bại)

• Giá giao ngay thời gian thực
• Phản ứng thị trường nhanh
• Kết quả: Hiệu ứng dây chuyền 19 tỷ USD

Đây là cách tiếp cận kiểu bZx/Harvest: tin vào thị trường giao ngay, bị tiêu diệt bởi thao túng.

Phương án ổn định cao (Các nền tảng DeFi sống sót)

• Mã hóa cứng USDe = USDT
• Bỏ qua biến động tạm thời
• Kết quả: Không có thanh lý

Đây là phản ứng quá mức. Đỡ thảm họa hơn, nhưng chưa tối ưu.

Ngành đã có năm năm để phát triển giải pháp tinh chỉnh. Nhưng kết quả là hai thái cực tồn tại, và quy mô tổ chức lại chọn phương án thảm họa.

Định lý tấn công Oracle: Đã được kiểm chứng thực tế

Định lý: Trong bất kỳ hệ thống có đòn bẩy nào mà:

1. Giá oracle phụ thuộc chủ yếu vào thị trường giao ngay dễ thao túng
2. Ngưỡng thanh lý xác định
3. Hạ tầng có giới hạn năng lực

Thì: Chi phí thao túng < Giá trị khai thác được qua hiệu ứng dây chuyền

Chứng minh qua thực nghiệm lặp lại:

• bZx (tháng 2/2020): Thao túng Uniswap → thu 350.000 USD + 630.000 USD
• Harvest (tháng 10/2020): Thao túng Curve → mất 24 triệu USD + rút tiền hàng loạt 570 triệu USD
• Compound (tháng 11/2020): Thao túng Coinbase → thanh lý 89 triệu USD
• Mango (tháng 10/2022): Thao túng đa sàn → thu 117 triệu USD
• Tháng 10 năm 2025: Thao túng sàn chính → mất 19,3 tỷ USD

Khi quy mô hệ thống tăng tuyến tính, mức thiệt hại tăng theo cấp số nhân. Chi phí thao túng gần như không đổi (quyết định bởi thanh khoản sàn), nhưng giá trị khai thác tăng theo tổng đòn bẩy toàn hệ thống.

Tháng 10 năm 2025 xác thực định lý ở quy mô chưa từng có.

Nguyên tắc thiết kế Oracle: Bài học lẽ ra phải thuộc nằm lòng

1. Xác thực đa nguồn

Không bao giờ dựa vào giá từ một sàn, nhất là từ sổ lệnh nội bộ. Đây là bài học từ bZx tháng 2 năm 2020. Oracle chuẩn cần:

Giá Oracle = Trung bình trọng số của:

• Giá nhiều sàn (40%)

• Pool thanh khoản on-chain (30%)

• Tỷ lệ chuyển đổi tài sản wrapped (20%)

• Giá lịch sử trọng số thời gian (10%)

Trọng số không quan trọng bằng tính độc lập. Nếu mọi nguồn đều có thể bị thao túng cùng lúc, thực chất bạn chỉ có một nguồn.

1. Độ nhạy thích ứng

Oracle cần điều chỉnh độ nhạy theo điều kiện thị trường:

• Thị trường bình thường: Độ nhạy cao với biến động giá
• Thị trường biến động: Tăng ổn định nhờ trọng số thời gian
• Biến động cực đoan: Bộ ngắt mạch và kiểm tra hợp lý

Oracle TWAP được áp dụng rộng rãi sau các vụ tấn công flash loan năm 2020 để ngăn thao túng giao dịch đơn lẻ. Nhưng oracle tháng 10 năm 2025 vẫn phản ứng với giá giao ngay thực tế, như thể năm năm trước chưa từng xảy ra.

1. Khả năng phục hồi hạ tầng

Hệ thống oracle phải duy trì vận hành khi xảy ra hiệu ứng dây chuyền:

• Hạ tầng tách biệt cho nguồn giá
• Khả năng xử lý hàng triệu truy vấn đồng thời
• Thoát tải trơn tru khi quá tải

Sau khi Harvest Finance sụp đổ hạ tầng tháng 10 năm 2020, vai trò năng lực hệ thống trong sự kiện căng thẳng đã quá rõ. Thanh lý dây chuyền tạo tải tăng cấp số nhân. Hạ tầng phải đáp ứng không chỉ thanh lý đầu tiên, mà cả nghìn thanh lý đồng thời khi market makers không kịp phản ứng, người dùng hoảng loạn.

1. Minh bạch mà không tạo lỗ hổng

Cửa sổ tám ngày giữa thông báo và thực thi tạo điểm tấn công lộ diện. Cách tốt hơn:

• Thực thi ngay sau khi thông báo
• Cập nhật luân phiên, không cố định ngày
• Giữ nhật ký kiểm toán mà không có thời gian xem trước

Đây là bài học mới, nhưng logic theo lý thuyết trò chơi: không công bố trước các thay đổi có thể bị khai thác. Kẻ tấn công tháng 10 năm 2025 có tám ngày để chuẩn bị. Họ biết chính xác khi nào cửa sổ lỗ hổng mở ra.

Góc nhìn học thuật: Định lý tấn công Oracle

Năm năm thực nghiệm chứng minh:

Định lý: Trong hệ thống đòn bẩy mà:

1. Giá oracle phụ thuộc chủ yếu vào thị trường giao ngay dễ thao túng
2. Ngưỡng thanh lý xác định
3. Hạ tầng có giới hạn năng lực

Thì: Chi phí thao túng < Giá trị khai thác được qua hiệu ứng dây chuyền

Chứng minh lặp lại:

• bZx (tháng 2/2020): Vay 10 triệu USD, thu 350.000 USD qua thao túng Uniswap.
• Harvest (tháng 10/2020): Flash loan 50 triệu USD, mất 24 triệu USD + rút tiền hàng loạt 570 triệu USD.
• Compound (tháng 11/2020): Thao túng sổ lệnh 100.000 USD, bị thanh lý 89 triệu USD.
• Mango (tháng 10/2022): Vốn ban đầu 5 triệu USD, thu 117 triệu USD.
• Tháng 10 năm 2025: Bán tháo giao ngay 60 triệu USD, hủy hoại 19,3 tỷ USD.

Quy luật rõ ràng: Quy mô hệ thống tăng tuyến tính, thiệt hại tăng cấp số nhân. Chi phí thao túng gần như không đổi (do thanh khoản sàn), nhưng giá trị khai thác tăng theo tổng đòn bẩy hệ thống.

Tháng 10 năm 2025 xác thực định lý ở quy mô chưa từng có. Định lý đúng.

Hệ quả hệ thống: Bài học vẫn chưa được học

Đây không chỉ là thất bại của một nền tảng—nó phơi bày lỗ hổng toàn ngành dù đã có năm năm bài học đắt giá:

1. Quá phụ thuộc vào giá giao ngay

Phần lớn nền tảng vẫn dùng oracle thiên về giá giao ngay dù mọi vụ tấn công lớn từ năm 2020 đều khai thác đúng điểm yếu này. Ngành biết giá giao ngay dễ thao túng. Ngành biết TWAP và oracle đa nguồn bảo vệ tốt hơn. Nhưng triển khai vẫn chưa đầy đủ.

Tại sao? Tốc độ và độ nhạy là tính năng cho tới khi thành lỗ hổng. Cập nhật giá thời gian thực tưởng như chính xác—cho tới khi bị thao túng.

2. Rủi ro tập trung

Sàn lớn tạo điểm thất bại đơn lẻ. Điều này đã rõ khi bZx dựa vào Uniswap, Compound vào Coinbase, nền tảng tháng 10 năm 2025 vào sổ lệnh nội bộ. Sàn giao dịch thay đổi; lỗ hổng vẫn còn.

Khi một sàn chiếm ưu thế về khối lượng, dùng nó làm nguồn oracle chính có vẻ hợp lý. Nhưng rủi ro tập trung trong nguồn giá cũng như mọi hệ thống: ổn cho tới khi bị khai thác.

3. Giả định hạ tầng

Hệ thống thiết kế cho điều kiện bình thường sẽ thất bại thảm hại khi căng thẳng. Harvest Finance đã chứng minh năm 2020. Tháng 10 năm 2025 chứng minh ta vẫn thiết kế cho điều kiện bình thường và hy vọng không xảy ra sự cố.

Hy vọng không phải chiến lược.

4. Nghịch lý minh bạch

Công bố cải tiến tạo ra cửa sổ tấn công. Khoảng cách tám ngày giữa thông báo và thực thi thay đổi oracle cho phép đối tượng tinh vi lên kế hoạch và xác định thời điểm tấn công.

Đây là kiểu thất bại mới cho vấn đề cũ. Các vụ tấn công oracle trước khai thác lỗ hổng sẵn có. Tháng 10 năm 2025 khai thác quá trình chuyển đổi phương pháp oracle—chỉ xuất hiện vì cải tiến công bố trước khi thực thi.

Lộ trình phía trước: Thực sự rút ra bài học

Cải tiến ngay

1. Thiết kế Oracle laiKết hợp nhiều nguồn giá với kiểm tra hợp lý thực sự hiệu quả:

• Giá CEX (trọng số theo khối lượng nhiều sàn)
• Giá DEX (chỉ từ pool thanh khoản lớn)
• Bằng chứng dự trữ on-chain
• Giới hạn chênh lệch giá giữa các sàn

Mỗi nguồn phải độc lập. Nếu thao túng một nguồn ảnh hưởng nguồn khác, bạn không có dự phòng.

2. Trọng số độngĐiều chỉnh độ nhạy oracle theo điều kiện thị trường:

• Biến động bình thường: Trọng số chuẩn
• Biến động cao: Tăng cửa sổ TWAP, giảm ảnh hưởng giá giao ngay
• Biến động cực đoan: Tạm dừng thanh lý, kiểm tra trước khi tiếp tục

Vụ Compound cho thấy đôi khi giá “đúng” trên một sàn lại sai với toàn thị trường. Oracle cần đủ thông minh để nhận ra.

3. Bộ ngắt mạchTạm dừng thanh lý khi giá biến động cực đoan—không để ngăn giảm đòn bẩy hợp lý, mà để phân biệt thao túng với thực tế thị trường:

• Nếu giá hội tụ trên các sàn trong vài phút: khả năng cao là thật
• Nếu giá chỉ biến động trên một sàn: khả năng cao là thao túng
• Nếu hạ tầng quá tải: tạm dừng đến khi khôi phục năng lực

Không nhằm ngăn mọi thanh lý. Mục tiêu là ngăn thanh lý dây chuyền do giá bị thao túng.

4. Nâng cấp hạ tầngThiết kế cho năng lực gấp 100 lần bình thường vì hiệu ứng dây chuyền tạo ra tải như vậy:

• Hạ tầng tách biệt cho nguồn giá
• Công cụ thanh lý độc lập
• Giới hạn tốc độ cho từng địa chỉ
• Quy trình giảm tải trơn tru

Nếu hệ thống không đáp ứng khi hiệu ứng dây chuyền xảy ra, nó sẽ khuếch đại thảm họa. Đây là yêu cầu thiết kế, không phải tối ưu hóa.

Giải pháp dài hạn

1.Mạng lưới Oracle phi tập trungChuyển sang giải pháp oracle trưởng thành như Chainlink, Pyth hay UMA tích hợp đa nguồn và kháng thao túng. Không hoàn hảo, nhưng tốt hơn oracle phụ thuộc giá giao ngay bị khai thác định kỳ. bZx tích hợp Chainlink sau các vụ tấn công năm 2020 và không còn bị thao túng oracle. Đó không phải trùng hợp.

2.Tích hợp bằng chứng dự trữĐối với tài sản wrapped và stablecoin, xác thực giá trị tài sản thế chấp on-chain. USDe cần định giá dựa trên dự trữ xác minh được, không dựa vào sổ lệnh. Công nghệ có sẵn; triển khai còn chậm.

3.Thanh lý từng bướcNgăn hiệu ứng khuếch đại dây chuyền qua thanh lý phân đoạn:

• Ngưỡng đầu: Cảnh báo và thời gian bổ sung tài sản thế chấp
• Ngưỡng hai: Thanh lý một phần (25%)
• Ngưỡng ba: Thanh lý lớn hơn (50%)
• Ngưỡng cuối: Thanh lý toàn bộ
  Giúp người dùng có thời gian phản ứng, giảm sốc hệ thống do thanh lý hàng loạt.

4.Kiểm toán thời gian thựcTheo dõi dấu hiệu thao túng oracle:

• Chênh lệch giá giữa các sàn
• Khối lượng bất thường ở cặp thanh khoản thấp
• Kích thước vị thế tăng nhanh trước khi oracle cập nhật
• Phát hiện mẫu hành vi giống các vụ tấn công trước

Vụ tấn công tháng 10 năm 2025 chắc chắn có dấu hiệu cảnh báo. Ai đó bán tháo 60 triệu USD USDe lúc 05:43 phải kích hoạt cảnh báo. Nếu hệ thống giám sát không phát hiện, cần nâng cấp.

Kết luận: Bài học 19 tỷ USD

Hiệu ứng dây chuyền thanh lý ngày 10-11 tháng 10 không phải do quá mức đòn bẩy hay hoảng loạn thị trường—mà do thiết kế oracle thất bại ở quy mô lớn. Một hành động 60 triệu USD đã khuếch đại thành thảm họa 19 tỷ USD vì hệ thống giá không phân biệt được thao túng với biến động thực.

Nhưng đây không phải kiểu thất bại mới. Chính lỗ hổng này đã phá hủy bZx tháng 2 năm 2020, Harvest tháng 10 năm 2020, Compound tháng 11 năm 2020, và Mango tháng 10 năm 2022.

Ngành đã học bài học này năm lần, với chi phí ngày càng tăng:

• 2020: Các giao thức riêng lẻ rút kinh nghiệm, sửa lỗi
• 2022: Cơ quan quản lý nhận thức, bắt đầu xử lý
• 2025: Toàn thị trường học, trả “học phí” 19,3 tỷ USD

Giờ chỉ còn câu hỏi: liệu chúng ta có nhớ bài học này không.

Mỗi nền tảng giao dịch ký quỹ phải tự hỏi:

• Oracle của chúng ta có chống lại các kiểu tấn công từ 2020-2022?
• Hạ tầng có chịu được hiệu ứng dây chuyền từng xảy ra?
• Đã cân bằng độ nhạy và ổn định chưa?
• Có lặp lại sai lầm gây thiệt hại hàng trăm triệu USD không?

Năm năm lịch sử chứng minh, thao túng oracle không phải rủi ro giả định hay trường hợp ngoại lệ—mà là chiến lược tấn công thực tế, lặp lại, sinh lợi, tỷ lệ thuận với quy mô thị trường.

Tháng 10 năm 2025 chỉ ra điều gì xảy ra khi bài học này bị lãng quên ở quy mô tổ chức. Vụ tấn công không tinh vi hay mới mẻ. Chỉ là lặp lại kịch bản cũ, nhắm vào hệ thống lớn hơn, đúng cửa sổ lỗ hổng đã báo trước.

Oracle là nền móng. Khi nó nứt vỡ, mọi thứ phía trên đều sụp đổ. Chúng ta đã biết điều này từ tháng 2 năm 2020. Đã trả hàng tỷ USD để học lại nhiều lần. Giờ chỉ còn chờ xem liệu tháng 10 năm 2025 có đủ đắt để buộc ngành phải hành động theo kiến thức đã có hay không.

Trong thị trường liên kết hiện đại, thiết kế oracle không chỉ là dữ liệu—mà là sự ổn định hệ thống. Làm sai, 60 triệu USD có thể thổi bay 19 tỷ USD.

Lặp lại sai lầm, bạn không học từ lịch sử. Chỉ càng tốn kém cho việc lặp lại quá khứ.

Bài phân tích dựa trên dữ liệu công khai, phát ngôn nền tảng và năm năm nghiên cứu các vụ thao túng oracle. Quan điểm cá nhân, dựa trên tham khảo chứ không đại diện cho bất kỳ tổ chức nào.

Miễn trừ trách nhiệm:

1. Bài viết này đăng lại từ [yq_acc]. Tất cả bản quyền thuộc tác giả gốc [yq_acc]. Nếu có khiếu nại về việc đăng lại, vui lòng liên hệ đội ngũ Gate Learn để được xử lý kịp thời.
2. Miễn trừ trách nhiệm: Quan điểm và nhận định trong bài viết này hoàn toàn của tác giả, không cấu thành khuyến nghị đầu tư.
3. Bản dịch sang các ngôn ngữ khác do đội ngũ Gate Learn thực hiện. Trừ khi được phép, nghiêm cấm sao chép, phân phối hoặc đạo văn bản dịch.