Hướng dẫn bảo mật hệ sinh thái Pharos: Kiểm soát rủi ro Chuỗi cho tích hợp tài sản RWA

Bài viết này được dịch máy
Xem bản gốc

Bài viết này nhằm cung cấp cho các nhà phát triển trong hệ sinh thái Pharos một tham khảo thực tiễn và độ sâu hơn về tích hợp tài sản thực (RWA). Chúng tôi cố gắng tái cấu trúc những thách thức và giải pháp phức tạp gặp phải khi đưa tài sản thực (RWA) lên Chuỗi từ góc độ logic việc kinh doanh và kiến ​​trúc kiểm soát rủi ro.

giới thiệu

Hệ sinh thái Pharos hướng đến mục tiêu trở thành cơ sở hạ tầng kết nối tài sản tài chính truyền thống với thế giới Web3. Không giống như tài sản crypto truyền thống, Tài sản Thế giới Thực (RWA) sở hữu cả quyền vật lý ngoài chuỗithuộc tính giao dịch trên chuỗi . Bản chất kép này đòi hỏi ranh giới bảo mật của chúng không thể chỉ dừng lại ở cấp độ hợp đồng thông minh, mà phải mở rộng đến mọi khía cạnh của việc xác minh quyền sở hữu tài sản, đồng bộ hóa dữ liệu và tuân thủ quy định.

Dựa trên phân tích độ sâu về các dự án RWA chính thống [1], chúng tôi sẽ phác thảo các lộ trình chính cho các nhà phát triển Pharos để xây dựng các ứng dụng RWA mạnh mẽ từ ba khía cạnh: các mẫu kiến ​​trúc, các vùng rủi ro cốt lõi và các chiến lược tích hợp .

Tại sao Pharos lại phù hợp với RWA?

Pharos là một ứng dụng Lớp 1 được thiết kế cho các triển khai quy mô internet. Đối với các nhà phát triển RWA, không cần phải đi sâu vào các chi tiết về cơ chế đồng thuận; họ chỉ cần tập trung vào việc giải quyết hai vấn đề cốt lõi là quyết toán tài sản và tính toán phức tạp.

  1. Thực thi song song và hoàn tất giao dịch trong vòng chưa đầy một giây (Block-STM): Các EVM truyền thống xử lý giao dịch tuần tự, điều này dễ dẫn đến tắc nghẽn trong quá trình thanh toán RWA lớn hoặc tái cân bằng. Pharos giới thiệu công cụ thực thi song song Block-STM để đạt được khả năng hoàn tất giao dịch trong vòng chưa đầy một giây.

  • Điều này có nghĩa là tiền Chuỗi có thể được nhận và quyết toán trên Chuỗi có thể được hoàn tất gần như đồng thời, loại bỏ sự biến động tỷ giá và rủi ro trượt giá do "T+1" gây ra.

  1. Pharos hỗ trợ kiến ​​trúc máy ảo kép (EVM + WASM) với cả hoàn cảnh chạy EVM và WASM.

  • Lớp EVM: Chịu trách nhiệm về khả năng kết nối. Giao thức cho vay Solidity hiện có và mã DEX có thể được triển khai trực tiếp để hỗ trợ tài sản RWA.

  • Lớp WASM: Chịu trách nhiệm tính toán. RWA liên quan đến việc tính thuế lãi suất phức tạp, kiểm soát rủi ro theo cấp bậc và logic danh sách trắng tuân thủ, điều này tiêu tốn rất nhiều gas và không hiệu quả trên EVM. Logic tính toán chuyên sâu này có thể được chuyển sang mô-đun WASM để đạt được hiệu suất cao, chi phí thấp trong việc kiểm soát rủi ro Chuỗi.

Pharos

https://docs.pharosnetwork.xyz

II. Hai logic vận hành của RWA

Trước khi thiết kế giao thức RWA trên Pharos, các nhà phát triển cần làm rõ hai mô hình chuyển giao tài sản chính và các vòng cấp vốn của chúng:

  1. Chế độ Chuỗi sang ngoài Chuỗi

Đây hiện là mô hình phổ biến nhất, về cơ bản bao gồm huy động vốn Chuỗi và quản lý tài sản Chuỗi chuỗi. Nhà đầu tư đặt cọc stablecoin (như USDC) Chuỗi → nhóm dự án thu thập và chuyển đổi chúng thành tiền pháp định (USD) → đầu tư vào Chuỗi thanh khoản cao ( như trái phiếu kho bạc Mỹ) → lãi suất thu được lợi nhuận ngược trở lại Chuỗi và được phân phối cho người nắm giữ token .

Pharos

Nghiên cứu điển hình: $STBT của Matrixdock. Các nhà đầu tư được chứng nhận đúc$STBT (neo tỷ lệ 1:1 với trái phiếu Mỹ ), với số tiền thu được được nhóm dự án sử dụng để mua trái phiếu kho bạc. Người nắm giữ Chuỗi được hưởng lợi nhuận hàng năm khoảng 4,8%.

  1. Mô hình tài sản trên Chuỗi

Mô hình này tập trung vào việc chứng kho hóa và phân mảnh tài sản cụ thể. Nhóm dự án khóa tài sản ngoài Chuỗi cụ thể (như bất động sản) và định giá chúng → phát hành thị phần tương ứng của token ERC-20 → nhà đầu tư đăng ký bằng stablecoin → nhóm dự án chịu trách nhiệm bảo trì và vận hành tài sản Chuỗi → dòng tiền tạo ra (như tiền thuê nhà) được phân phối dưới dạng cổ tức trên Chuỗi định kì .

Pharos

Nghiên cứu điển hình: Token hóa bất động sản của RealT. Ví dụ, một bất động sản trị giá 65.900 đô la ở Detroit có thể được chia thành 1.300 token, và các nhà đầu tư mua vào token sẽ được hưởng một phần thu nhập cho thuê từ bất động sản đó.

III. Lập bản đồ rủi ro và chiến lược tích hợp Pharos

Rủi ro chết người của RWA thường không nằm ở chính mã nguồn, mà ở mối liên hệ giữa các cơ chế Chuỗi và Chuỗi. Các dự án RWA hiện có những lỗ hổng cấu trúc nghiêm trọng trong xác thực, neo giữ tài sản và tính minh bạch dữ liệu. Các nhà phát triển xây dựng ứng dụng trên Pharos nên tập trung vào việc phòng chống rủi ro"tê giác xám" sau đây.

Pharos

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

  1. Tuân thủ danh tính

Các dự án tuyên bố tuân thủ thường chỉ là hình thức. Thống kê cho thấy chưa đến một nửa số dự án thực hiện các thủ tục KYC (Xác minh danh tính khách hàng) hiệu quả; một số dự án có tiếng(như RealT) thậm chí còn bị vượt qua dễ dàng quy trình xác minh video chỉ bằng một bức ảnh. Mặc dù một số dự án nhấn mạnh AML (Chống phần mềm độc hại và điện toán đám mây) trong Sách trắng, trên thực tế, các giao dịch có thể được hoàn tất chỉ bằng cách kết nối ví điện tử, khiến việc truy tìm nguồn gốc tiền trở nên hoàn toàn bất khả thi.

Pharos

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Các khuyến nghị phát triển của Pharos:

  • Không chỉ thực hiện kiểm tra danh tính trên giao diện người dùng của trang web. Cần tích hợp cơ chế danh sách trắng ở lớp hợp đồng thông minh để đảm bảo rằng chỉ những địa chỉ đã được xác minh thông qua DID (Định danh phi tập trung) hoặc KYC Chuỗi chuỗi mới có thể gọi các chức năng đúc hoặc chuyển tiền. Lấy $STBT làm ví dụ, hãy viết lại các chức năng chuyển tiền và chuyển từ ERC-20 sao cho chỉ những địa chỉ được chứng nhận trong danh sách trắng mới có thể gọi chúng.

Pharos

https://etherscan.io/address/0x530824da86689c9c17cdc2871ff29b058345b44a#code

  • Đối với các giao dịch tài sản có giá trị ròng cao, cần áp dụng cơ chế xác thực hai yếu tố (2FA) để ngăn chặn hành vi trộm cắp tài sản do rò rỉ private key . Các nghiên cứu đã chỉ ra rằng cho đến nay chỉ có một vài dự án đạt được điều này. 

  1. Sự phụ thuộc vào Stablecoin và Cơ chế ngắt mạch

Stablecoin là huyết mạch của RWA, với gần 90% dự án dựa vào chúng quyết toán . Tuy nhiên, các nhà phát triển thường bỏ qua rủi ro tách rời vốn có trong stablecoin , chẳng hạn như rủi ro tách rời của USDC do sự cố SVB hoặc USDe [2]. Nếu sự tách rời xảy ra, liệu dự án có quỹ dự trữ rủi ro chuyên dụng để xử lý khủng hoảng không?

Pharos

https://x.com/ethena_labs/status/1976773136294224071

Các khuyến nghị phát triển của Pharos:

  • Oracle không chỉ nên được sử dụng để cung cấp thông tin giá cả, mà còn như các công cụ kiểm soát rủi ro. Khi giá của stablecoin được sử dụng làm tiền tệ quyết toán (như USDC/USDT) lệch khỏi tỷ giá tham chiếu quá một ngưỡng nhất định (ví dụ: 5%), hợp đồng nên tự động tạm dừng đúc và mua lại để ngăn chặn giao thức bị tấn công bởi hoạt động chênh lệch giá.

  • Khi thiết kế nhóm stablecoin , hãy cân nhắc hỗ trợ nhiều stablecoin hoặc thậm chí là một rổ tiền tệ để giảm thiểu tác động của rủi ro hệ thống từ một tài sản duy nhất. Đồng thời, tránh stablecoin Stablecoin thuật toán cơ chế phức tạp, vì chúng dễ bị tách rời nhất.

  1. Kết nối dữ liệu và xác minh tính xác thực

Vấn đề lớn nhất liên quan đến RWA nằm ở chỗ liệu tài sản Chuỗi có thực sự tương ứng với tài sản vật lý Chuỗi hay không. Nhiều dự án chỉ công khai một vài file PDF được đăng tải trên trang web; thậm chí còn có những trường hợp vô lý khi sử dụng các đoạn video ghi hình lặp lại để giả mạo việc giám sát thời gian thực. Báo cáo giá trị tài sản của OpenEden cũng bị trì hoãn đến cả tháng.

Pharos

https://dl.acm.org/doi/epdf/10.1145/3689931.3694913

Các khuyến nghị phát triển của Pharos:

  • Hãy tận dụng các mạng lưới oracle như Chainlink để kết nối trực tiếp với API của các ngân hàng lưu ký hoặc công ty kiểm toán ngoài Chuỗi . Các nhà phát triển Pharos nên tập trung vào việc Chuỗi Giá trị tài sản (NAV) trên chuỗi ở mức độ từng phút, thay vì dựa vào báo cáo hàng tháng hoặc hàng quý từ các nhóm dự án.

  • Sự chênh lệch về định giá dự án là một rủi ro thường xuyên xảy ra. Trong quá trình phát triển, cần phải tích hợp nhiều nguồn cấp dữ liệu giá oracle để đảm bảo giá Chuỗi phản ánh chính xác nhất có thể điều kiện thị trường Chuỗi .

  1. Phân tách và minh bạch các thực thể pháp lý

Vỡ nợ tài sản Chuỗi chuỗi là rủi ro mà RWA không thể bỏ qua. Ví dụ, Goldfinch từng bị vỡ nợ tín dụng 5,9 triệu đô la[4]. Chìa khóa để cô lập rủi ro nằm ở SPV, nhưng chỉ một vài dự án đã công khai tuyên bố rằng họ sử dụng cấu trúc SPV, và hầu hết trong số họ không tiết lộ tên thực thể đã đăng ký cụ thể. Lấy cuộc khủng hoảng Goldfinch làm ví dụ, nó đã trực tiếp gây ra sự sụt giảm 20% token và các nhà đầu tư đã chịu tổn thất nghiêm trọng mà không có lý do.

Pharos

Các khuyến nghị phát triển của Pharos:

  • Tên pháp lý và địa điểm đăng ký của công ty mục đích đặc biệt (SPV) nắm giữ tài sản phải được công bố trong dữ liệu hoặc tài liệu dự án.

  • Hãy đảm bảo rằng mỗi nhóm tài sản tương ứng với một SPV độc lập. Trong thiết kế hợp đồng của Pharos, tiền trong các nhóm tài sản khác nhau phải được tách biệt hoàn toàn về mặt logic để tránh trường hợp một tài sản bị vỡ nợ dẫn đến toàn bộ giao thức cạn thanh khoản.

  1. Suy giảm thanh khoản sau giai đoạn thịnh vượng giả tạo

Thanh khoản là khía cạnh dễ ngụy tạo nhất của các dự án RWA nhưng cũng dễ sụp đổ nhất [2]. Độ sâu biểu đồ giá của nhiều dự án RWA ra mắt phụ thuộc rất nhiều vào trợ cấp nhà tạo lập thị trường . Khi thỏa thuận nhà tạo lập thị trường hết hạn hoặc trợ cấp ngừng, độ sâu thị trường thứ cấp thường giảm mạnh và các lệnh mua biến mất ngay lập tức. Ngoài ra, có sự không khớp thời gian tự nhiên giữa tần suất thấp của việc định giá tài sản Chuỗi chuỗi (thường là NAV hàng tháng hoặc hàng quý) và tần suất cao của các giao dịch trên Chuỗi(tạo khối cấp hai). Khi một lượng lớn bán ra xảy ra trên Chuỗi, nhóm AMM thường không thể nhanh chóng bổ sung do thiếu chỉ dẫn giá trị hợp lý theo thời gian thực, dẫn đến sự sai lệch nghiêm trọng của giá so với giá trị ròng và hình thành một lỗ đen thanh khoản. Ví dụ, trong hình dưới đây, do sự tháo chạy, giá token đã nhanh chóng giảm từ 1 đô la xuống 0,5 đô la trong vòng vài giờ [5].

Pharos

https://www.blocktempo.com/not-so-tangible-usdr-stablecoin-collapses/

Các khuyến nghị phát triển của Pharos:

  • Đừng mạo hiểm toàn bộ thanh khoản trên thị trường thứ cấp của DEX hoặc CEX. Các nhà phát triển có thể tích hợp hàng đợi mua lại/chuộc lại vào hợp đồng của họ. Khi giá thị trường thứ cấp thấp hơn đáng kể so với NAV (ví dụ: chiết khấu hơn 3%), người nắm giữ có thể bỏ qua thị trường thứ cấp và trực tiếp khởi tạo yêu cầu chuộc lại tài sản cơ sở của SPV cho giao thức, với hợp đồng thông minh quản lý hàng đợi chuộc lại và phân phối quỹ.

  • Theo hệ thống dự trữ của các ngân hàng truyền thống, một tỷ lệ nhất định (ví dụ: 5%-10%) stablecoin được bắt buộc giữ lại làm đệm thanh khoản Chuỗi trong quá trình Mint. Quỹ này không được sử dụng để mua tài sản ngoài Chuỗi , mà được sử dụng cụ thể để tự động thực hiện mua lại ngay lập tức thông qua hợp đồng thông minh nhằm bảo vệ mức giá sàn khi thanh khoản thị trường thứ cấp cạn kiệt.

  1. Rủi ro EVM

Pharos đạt được khả năng tương thích hoàn toàn với EVM, có nghĩa là các nhà phát triển có thể tận hưởng sự tiện lợi của hệ sinh thái Solidity đồng thời kế thừa đầy đủ các vectơ tấn công kinh điển của nó. Do các yêu cầu tuân thủ, các hợp đồng RWA thường chứa lượng lớn chức năng có đặc quyền cao (như blacklist, forceTransfer và pause), khiến việc quản lý quyền và nâng cấp proxy trở nên nhạy cảm hơn và là những điểm yếu nghiêm trọng hơn so với các giao thức DeFi.

Pharos

https://owasp.org/www-project-smart-contract-top-10/

Các khuyến nghị phát triển của Pharos:

  • Tuân thủ nghiêm ngặt các thư viện tiêu chuẩn: Tránh việc tự tạo lại những thứ đã có sẵn. Việc kiểm soát truy cập phải sử dụng AccessControl của OpenZeppelin hoặc Ownable2Step. Nếu private key của quản trị viên RWA bị đánh cắp do lỗ hổng logic tùy chỉnh, điều này có thể dẫn đến tranh chấp pháp lý liên quan đến quyền sở hữu tài sản vật lý Chuỗi .

  • Kiểm soát rủi ro nâng cấp tác nhân: Hầu hết các hợp đồng RWA đều nâng cấp(UUPS/Transparent). Khi triển khai các bản cập nhật, cần kiểm tra nghiêm ngặt các xung đột khe lưu trữ để ngăn chặn việc ghi đè biến phụ thuộc gây ra lỗi ánh xạ tài sản.

  • Phòng chống tấn công tái nhập: Khi xử lý logic phân phối lợi nhuận hoặc quy đổi, ngay cả đối với người dùng được đưa vào danh sách trắng, ReentrancyGuard phải được thêm vào tất cả các lệnh gọi bên ngoài để ngăn chặn các hợp đồng độc hại sử dụng các hàm điều chỉnh hồi nhằm rút cạn quỹ.

IV. Tóm tắt

Nhìn lại sự phát triển của lĩnh vực RWA (Quản lý tài sản theo thời gian thực), chúng ta đã chứng kiến ​​quá nhiều trường hợp thịnh vượng giả tạo được xây dựng dựa trên việc tuân thủ các quy định về giao diện người dùng và tạo lập thị trường để duy trì thanh khoản. Trong hệ sinh thái Pharos, chúng tôi ủng hộ một mô hình phát triển bền vững hơn.

Với tư cách là nhà phát triển, chúng ta cần nhận thức rõ rằng rủi ro bảo mật của RWA không chỉ giới hạn ở việc triển khai mã của hợp đồng thông minh. Các vấn đề như vô hiệu hóa quyền sở hữu tài sản Chuỗi và sự không khớp thanh khoản cũng cần được chú ý . Tính xác thực dưới một giây của Pharos mang lại cho chúng ta sự tự tin để xử lý việc kinh doanh tài chính phức tạp, nhưng điều này đòi hỏi các nhà phát triển phải chặt chẽ hơn trong chiến lược tích hợp của họ, kết hợp KYC/AML vào logic cơ bản, thực thi các cơ chế dự trữ rủi ro thông qua mã và tối đa hóa tính minh bạch dữ liệu tài sản .

Cuộc chiến trong tương lai cho các giao thức RWA sẽ không còn là cuộc đua về số lượng TVL, mà là cuộc cạnh tranh về tính xác thực tài sản và độ ổn định của hệ thống. Thiết lập một vòng lặp bảo mật cho chặng cuối này là điều bắt buộc đối với mọi nhà xây dựng hệ sinh thái Pharos.

Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận