DYOR là gì?

DYOR là viết tắt của "do your own research", tức tự mình nghiên cứu. Trong ngữ cảnh tài sản mã hóa, nó chỉ việc không lấy ngay phần quảng bá, bài đăng hay kết luận của người khác làm sự thật, mà tự tìm tài liệu gốc, đối chiếu chéo bằng chứng, và tách phần đã xác nhận khỏi phần vẫn còn chưa rõ.

DYOR không phải một hình thức chứng nhận thống nhất, cũng không phải cách làm cho dự án trở nên đáng tin hay cách tránh tổn thất. Nó giống một quy trình đối chiếu thông tin hơn: trước tiên xác định một phát biểu cụ thể khẳng định điều gì, rồi đánh giá tài liệu nào có thể hỗ trợ nó, tài liệu đó còn áp dụng được cho bản hiện tại hay không, và kết luận nào chỉ là phỏng đoán. Kết quả nghiên cứu cũng không phải một nhãn đơn giản kiểu "mua được" hay "không mua được".

Việc tự nghiên cứu bắt đầu từ một luận điểm đối chiếu được

"Dự án này tốt", "cộng đồng mạnh" hay "công nghệ dẫn đầu" đều rất khó kiểm chứng trực tiếp. Luận điểm càng cụ thể thì càng biết tìm bằng chứng ở đâu, ví dụ:

• một địa chỉ nào đó có phải là hợp đồng token mà dự án đang dùng hay không;
• tổng lượng token có thể tăng hay không, ai có quyền phát hành thêm;
• hợp đồng có thể tạm dừng, nâng cấp hoặc đóng băng một số thao tác hay không;
• khối lượng giao dịch hiển thị trên trang đến từ những thị trường và khoảng thời gian nào;
• một bản báo cáo kiểm toán nào đó kiểm tra phiên bản mã nào;
• một quan hệ hợp tác, tích hợp hay chức năng sản phẩm có được các bên liên quan xác nhận hay không;
• chức năng được tuyên bố đã hoạt động có tìm được bản ghi tương ứng trong mã nguồn, giao diện hay hoạt động trên chuỗi hay không.

Viết rõ luận điểm trước còn giúp khỏi trộn lẫn những câu hỏi khác nhau. Mã nguồn hợp đồng đã công khai không có nghĩa mã không có lỗ hổng; danh tính nhóm phát triển đã công khai không có nghĩa sản phẩm thực hiện được toàn bộ kế hoạch; có người giao dịch trên chuỗi cũng không có nghĩa những giao dịch đó đến từ người dùng độc lập hay thể hiện nhu cầu bền vững.

Những luận điểm khác nhau cần những loại bằng chứng khác nhau

Không nguồn nào một mình trả lời được mọi câu hỏi. Bằng chứng thường dùng khi nghiên cứu có thể chia thành vài loại:

"Nguồn chính thức" phù hợp để xác nhận dự án tự tuyên bố điều gì, nhưng nó vẫn là tài liệu do phía dự án công bố. Nguồn độc lập có thể đưa ra góc nhìn khác, cũng có thể dẫn lại thông tin sai hoặc đã lỗi thời. Kết luận đáng tin thường đến từ việc nhiều nguồn cùng chứng thực một luận điểm cụ thể, chứ không phải dán nhãn "đáng tin" cho một trang web rồi nhận toàn bộ nội dung của nó.

Hãy đối chiếu mạng và địa chỉ hợp đồng trước, rồi mới xem tên gọi và biểu tượng

Token trên chuỗi có thể trùng tên, cũng có thể dùng cùng biểu tượng và mã giao dịch. Khi nhận diện một tài sản số, tên mạng và địa chỉ hợp đồng thường có tính phân biệt cao hơn tên hiển thị; với token không thay thế được thì còn có thể cần đối chiếu số hiệu token.

Trang web hoặc tài liệu của dự án có thể cung cấp địa chỉ hợp đồng, còn trình khám phá block có thể hiển thị giao dịch triển khai, số dư, chuyển dịch token và lượt gọi hợp đồng của địa chỉ đó. Phần giới thiệu trình khám phá block của Ethereum.org liệt kê những dữ liệu trên chuỗi thường gặp như block, giao dịch, tài khoản, hợp đồng và token.

Địa chỉ vẫn phải đối chiếu chéo. Trang web giả mạo cũng có thể trưng ra một hợp đồng tồn tại thật, kết quả tìm kiếm và bài đăng trên mạng xã hội cũng có thể trỏ tới token giả cùng tên. Dấu "đã xác thực" trên trang cụ thể nghĩa là gì thì tùy quy tắc xác thực của dịch vụ đó, không thể chỉ dựa vào biểu tượng hay nhãn mà kết luận.

Bản ghi trên chuỗi chứng minh được điều gì đã xảy ra, nhưng không tự động giải thích tại sao

Blockchain có thể ghi lại một địa chỉ phát giao dịch vào lúc nào, tài sản chuyển dịch thế nào, và trạng thái hợp đồng thay đổi thế nào. Loại bản ghi này phù hợp để đối chiếu biến động lượng cung, hướng đi của dòng tiền, phiếu quản trị và việc một chức năng nhất định có bị gọi tới hay không.

Bản ghi trên chuỗi thường không trực tiếp cho người đọc biết danh tính thật sau địa chỉ, và một mình nó cũng không giải thích được mục đích của một giao dịch. Một người có thể kiểm soát nhiều địa chỉ, nhiều người cũng có thể thao tác qua cùng một địa chỉ của nền tảng lưu ký. Số lượng địa chỉ không thể quy trực tiếp thành số lượng người dùng, số lần chuyển dịch token cũng không thể quy trực tiếp thành mức độ được sử dụng thực tế.

Dữ liệu trên chuỗi còn có thể qua lập chỉ mục, gắn nhãn và tính toán rồi mới hiển thị. Những trường giao dịch đối chiếu độc lập được trên chuỗi thuộc bản ghi giao thức, còn nhãn địa chỉ, cách phân loại người nắm giữ và biểu đồ thống kê do dịch vụ cung cấp thì có thêm phần phán đoán. Khi dùng loại kết quả này, cần xem cách tính, phạm vi mạng và thời điểm cập nhật.

Mã nguồn đã xác thực chỉ nói lên mã khớp với bản đã triển khai

Hợp đồng thông minh là chương trình được triển khai trên blockchain, thực thi thao tác theo mã của nó. Ở những mạng dùng Máy ảo Ethereum (Ethereum Virtual Machine, EVM) như Ethereum, việc xác thực mã nguồn thường biên dịch lại mã công khai theo cùng thiết lập, rồi so với mã máy đang thực sự chạy tại địa chỉ hợp đồng. Mã máy là kết quả biên dịch để mạng thực thi trực tiếp. Phần hướng dẫn xác thực hợp đồng của Ethereum.org tách việc kiểm tra khớp này khỏi việc kiểm chứng hình thức; kiểm chứng hình thức là dùng phương pháp toán học để kiểm tra chương trình có thỏa mãn những tính chất đã chỉ định trước hay không. Những mạng khác thì phải đối chiếu mã chương trình theo cơ chế triển khai và phiên bản của riêng chúng.

Vì vậy, "mã hợp đồng đã xác thực" thường chỉ nói lên phần mã mà người đọc thấy khớp được với chương trình trên chuỗi, không có nghĩa mã đã qua kiểm toán an toàn, cũng không có nghĩa chương trình không có lỗ hổng logic. Phần chú thích và tên biến trong mã công khai cũng có thể gây nhầm lẫn; hành vi thực tế phải xem phần logic thực thi được.

Còn phải xác định xem hợp đồng cửa vào có chuyển tiếp yêu cầu sang một bản mã triển khai khác hay không. Loại cửa vào này thường gọi là hợp đồng proxy. Proxy nâng cấp được cho phép tài khoản có quyền tương ứng thay bản mã triển khai; tài liệu hợp đồng proxy của OpenZeppelin giải thích cách proxy, hợp đồng triển khai và người quản trị nâng cấp phối hợp với nhau. Chỉ đọc đoạn mã ngắn của chính địa chỉ proxy thì có thể bỏ sót cả hợp đồng thật sự thực thi chức năng lẫn phần quyền nâng cấp.

Kho mã cho thấy quá trình phát triển, không đồng nghĩa với chức năng đang chạy

Kho mã công khai có thể cho thấy tệp, bản ghi commit, nhãn phiên bản, phần thảo luận vấn đề và người đóng góp. Commit là một lần thay đổi mã được ghi lại, còn nhãn phiên bản thường dùng để đánh dấu một lần phát hành. Chúng có thể giúp đối chiếu dự án có liên tục sửa mã hay không, một chức năng được thêm vào khi nào, và giữa các phiên bản đã đổi những gì.

Phần hướng dẫn về hoạt động kho mã của GitHub trình bày những bản ghi như đẩy mã, gộp nhánh, đẩy ép và thay đổi nhánh. Hoạt động nhiều không có nghĩa chất lượng mã cao, commit ít cũng không hẳn là dự án đã dừng; việc cập nhật tự động, mã sao chép lại và phần phát triển không diễn ra ở kho công khai đều ảnh hưởng tới số liệu bề mặt.

Mã trong kho còn phải tương ứng với bản triển khai thực tế. Khi nghiên cứu một ứng dụng trên chuỗi, nên xem nhãn phát hành, bản ghi triển khai hay thông tin xác thực hợp đồng có nối được phiên bản trong kho với địa chỉ trên chuỗi hay không; nếu không thì chỉ xác nhận được "trong kho có bản mã này", chứ không xác nhận được nó đang chạy.

Báo cáo kiểm toán phải xem phạm vi, phiên bản, ngày tháng và cách xử lý kết quả

Kiểm toán an toàn là việc người có chuyên môn kiểm tra mã, thiết kế hoặc giả định vận hành trong một phạm vi và thời gian nhất định, rồi ghi lại những vấn đề phát hiện được. Khi đọc báo cáo, điều quan trọng không chỉ là "đã từng kiểm toán", mà còn gồm:

• những tệp, địa chỉ hợp đồng hoặc commit mã được kiểm tra có ghi rõ hay không;
• sau khi kiểm toán xong, mã có thay đổi lớn nữa hay không;
• những thành phần, phần phụ thuộc bên ngoài và điều kiện vận hành nào nằm ngoài phạm vi kiểm tra;
• báo cáo phát hiện những vấn đề nào, dự án phản hồi thế nào;
• phần khắc phục có được rà soát lại hay không, vấn đề chưa khắc phục có còn tồn tại hay không;
• báo cáo có do bên kiểm toán công bố hay không, đường dẫn có trỏ tới tệp đầy đủ hay không.

Kiểm toán không chứng minh được rằng không tồn tại lỗ hổng chưa biết. Tài liệu chuẩn bị lên mạng chính của OpenZeppelin cũng nói rõ kiểm toán không bảo đảm mã không có lỗi. Lấy bản cũ, một phần mô-đun hoặc báo cáo chưa rà soát lại làm bằng chứng an toàn cho cả hệ thống thì vượt quá phạm vi mà bản thân báo cáo có thể hỗ trợ.

Sách trắng trình bày kế hoạch, không đồng nghĩa với bản ghi đã hoàn thành

Sách trắng thường giới thiệu vấn đề mà dự án muốn giải quyết, hướng thiết kế, cách thu xếp token hay kế hoạch phát triển. Nó phù hợp để xác nhận phía dự án đã công khai đặt ra mục tiêu gì, nhưng một mình nó không chứng minh được mục tiêu đã đạt được.

Khi nghiên cứu, có thể đối chiếu riêng từng luận điểm kiểm chứng được trong sách trắng với tài liệu hiện tại, các bản phát hành mã, phần triển khai trên chuỗi và chức năng thực tế. Mốc lộ trình đã qua mà không có bản ghi phát hành tương ứng, quy tắc token không khớp với hợp đồng đã triển khai, hay tài liệu lâu không cập nhật, đều là những điểm khác biệt cần tiếp tục xác nhận; bản thân chúng không nhất thiết chứng minh dự án có gian dối.

Tài liệu còn có thể đang mô tả bản cũ. Ngày công bố trang, lần sửa gần nhất, mạng áp dụng và số phiên bản sẽ quyết định một đoạn thuyết minh có dùng được cho hệ thống hiện tại hay không. Khi không có thông tin ngày tháng hay phiên bản, nên ghi kết luận là chưa chắc chắn, chứ không tự ý bù vào phần bối cảnh còn thiếu.

Độ nóng trên mạng xã hội không phải bằng chứng về sự thật

Lượt thích, lượt chia sẻ, số thành viên nhóm và độ nóng tìm kiếm mô tả mức độ lan truyền của nội dung; chúng không trực tiếp chứng minh được chức năng kỹ thuật, danh tính người dùng, mức an toàn của dòng tiền hay nhu cầu thị trường. Tài khoản có thể bị giả mạo, bị chiếm, phần tương tác cũng có thể đến từ chương trình tự động hoặc hoạt động quảng bá có phối hợp.

Mạng xã hội phù hợp hơn để phát hiện những luận điểm cần đối chiếu, chứ không phải làm bằng chứng duy nhất cho một luận điểm. Khi liên quan tới địa chỉ hợp đồng, việc cập nhật phiên bản, sự cố an toàn hay quan hệ bên ngoài, có thể trở lại tài liệu dự án, kho mã, bản ghi trên chuỗi và tuyên bố gốc của các bên liên quan để xác nhận.

Nguồn có công bố quan hệ lợi ích hay không cũng quan trọng. Người viết nội dung có thể đang nắm token liên quan, nhận thù lao, tham gia dự án hoặc hưởng lợi qua đường dẫn giới thiệu. Không công bố thì không hẳn chứng minh nội dung sai, nhưng người đọc không thể dựa vào đó để đánh giá xung đột lợi ích tiềm tàng, nên trọng số của bằng chứng ấy cần tách khỏi những tài liệu đối chiếu độc lập được.

Một quy trình đối chiếu hoàn chỉnh sẽ giữ lại những câu hỏi chưa giải quyết

Kết quả của DYOR không nên chỉ là một dãy đường dẫn, mà còn nên nói rõ từng bằng chứng đã trả lời điều gì. Một quy trình đối chiếu thông tin dùng chung có thể ghi lại như sau:

1. viết lại một đánh giá mơ hồ thành một luận điểm cụ thể, kiểm chứng được;
2. tìm tài liệu gốc gần nhất với luận điểm đó, và ghi lại bên công bố, ngày tháng và phiên bản;
3. dùng bản ghi trên chuỗi, mã nguồn, báo cáo đầy đủ hoặc một nguồn độc lập khác để đối chiếu chéo;
4. phân biệt sự thật quan sát trực tiếp, suy luận dựa trên sự thật, và ý kiến cá nhân;
5. ghi lại những điểm xung đột giữa các nguồn, và vẫn còn thiếu bằng chứng gì;
6. khi hợp đồng, quyền hạn, phiên bản hay quan hệ bên ngoài không xác nhận được thì giữ "chưa chắc chắn", không coi chỗ trống là kết luận khẳng định hay phủ định.

Cùng một kết luận nghiên cứu sẽ mất hiệu lực theo thời gian. Hợp đồng có thể nâng cấp, quyền quản trị có thể chuyển giao, tài liệu và phạm vi kiểm toán có thể đổi, thanh khoản và phân bố token cũng biến động. Khi dẫn thông tin động, cần giữ lại mốc thời gian của dữ liệu, không viết một lần kiểm tra thành kết luận vĩnh viễn.

Những dấu hiệu cảnh báo thường gặp cần tiếp tục đối chiếu, chứ không phải kết tội ngay

Những tình huống dưới đây cho thấy tài liệu hiện có không đủ hoặc đang xung đột, cần đối chiếu thêm:

• địa chỉ hợp đồng chỉ xuất hiện trong bài đăng hoặc tin nhắn riêng không xác nhận được nguồn gốc;
• tên gọi, biểu tượng và mã giao dịch giống nhau, nhưng mạng thuộc về hoặc địa chỉ hợp đồng lại khác;
• trang tuyên bố mã nguồn mở, nhưng không có kho mã hay bản ghi xác thực tương ứng với bản đã triển khai;
• tuyên bố đã qua kiểm toán, nhưng không cung cấp báo cáo đầy đủ, phiên bản được kiểm tra hay tình trạng khắc phục;
• phần thuyết minh về lượng cung hay quyền hạn trong sách trắng không khớp với hành vi hợp đồng hiện tại;
• dùng những cách nói như "bảo đảm lợi nhuận", "không có rủi ro" hoặc tạo cảm giác gấp gáp;
• tuyên bố được tổ chức bên ngoài hậu thuẫn, nhưng bên liên quan không có thuyết minh tương ứng đối chiếu được;
• người quản trị có thể nâng cấp, tạm dừng hoặc chuyển tài sản, nhưng phần công bố không hề nhắc tới những quyền này;
• ảnh chụp dữ liệu không có nguồn, khoảng thời gian hay đường dẫn tra lại được;
• phần thảo luận chỉ dẫn lại những bài đăng chuyển tiếp lẫn nhau, cuối cùng không tìm được tài liệu gốc.

Một dấu hiệu cảnh báo đơn lẻ không tự động chứng minh dự án gian lận. Chẳng hạn, nhóm phát triển không công khai toàn bộ danh tính, mã ít được cập nhật, hay hợp đồng có quyền quản trị, đều có thể vì những lý do khác nhau. Kết luận cần tương ứng với cam kết cụ thể, cấu trúc kỹ thuật và những bản ghi đối chiếu được.

DYOR có giới hạn, và không nên dùng để đẩy trách nhiệm cho người bị hại

Người đọc phổ thông không thể tự mình kiểm toán toàn bộ mã, xác minh mọi thông tin về nhóm phát triển hay phát hiện một cuộc tấn công chuyên nghiệp. Thông tin có thể bị che giấu có chủ ý, giao diện và tài khoản có thể bị giả mạo, kiểm toán và dữ liệu công khai cũng có thể có điểm mù. Việc tự nghiên cứu chỉ giảm được một phần khoảng trống thông tin, không thể biến mọi rủi ro chưa biết thành đã biết.

Câu "bạn nên tự nghiên cứu" cũng không thay được việc phía dự án công bố chính xác những thông tin quan trọng, và không bào chữa được cho phát biểu sai sự thật. Khi có người chịu tổn thất vì bị dẫn dụ, bị giả mạo hay vì lỗ hổng kỹ thuật, việc chỉ trích đơn giản rằng họ "không DYOR" đã bỏ qua sự bất đối xứng thông tin và ngưỡng chuyên môn.

Khi vấn đề cần tới phán đoán chuyên môn về kỹ thuật, an toàn, thuế hay pháp lý, việc đối chiếu thông tin thông thường không thể phủ cùng phạm vi bằng chứng và cùng mức trách nhiệm.

Câu hỏi thường gặp

Đọc sách trắng rồi có coi là đã làm DYOR?

Không. Sách trắng chủ yếu nói về mục tiêu và thiết kế của phía dự án. Vẫn phải đối chiếu xem mã hiện tại, phần triển khai, quyền hạn, hoạt động trên chuỗi, phạm vi kiểm toán và phiên bản tài liệu có khớp với những thuyết minh đó hay không.

Mã hợp đồng đã xác thực thì có nghĩa là an toàn?

Không. Việc xác thực mã nguồn chủ yếu xác nhận mã công khai khớp với mã máy đã triển khai, không tự động phát hiện mọi lỗ hổng logic, cũng không xóa được quyền nâng cấp, phần phụ thuộc bên ngoài và rủi ro vận hành.

Dữ liệu trên chuỗi không làm giả được, vậy kết luận rút ra từ đó chắc chắn đáng tin?

Bản ghi giao dịch trên chuỗi thì kiểm chứng được, nhưng nhãn địa chỉ, việc quy danh tính, số lượng người dùng và động cơ giao dịch thường cần thêm phần giải thích. Cách tính sai, hoặc coi nhiều địa chỉ thành nhiều người dùng, cũng sẽ cho ra kết luận sai.

Nhóm phát triển ẩn danh thì nhất định không đáng tin?

Không thể chỉ dựa vào việc có ẩn danh hay không mà kết luận. Danh tính công khai có thể làm tăng phần thông tin đối chiếu được, nhưng không chứng minh được gì về mã nguồn, mức an toàn hay cam kết; còn ẩn danh thì làm giảm tài liệu kiểm chứng được về danh tính và quá trình hoạt động, và cần ghi rõ khoảng trống thông tin này.

DYOR có nói cho tôi biết nên mua loại tài sản nào không?

Không. DYOR là quy trình đối chiếu thông tin, nguồn và những điểm chưa rõ; nó không tự động cho ra kết luận mua, bán hay nắm giữ phù hợp với một người cụ thể, và cũng không dự đoán được giá trong tương lai.

Khái niệm liên quan

Tìm hiểu thêm về tài sản số, hợp đồng thông minh, token mã hóa và khóa riêng tư, hoặc trở lại bảng thuật ngữ tiền mã hóa.

Nguồn

• Ethereum.org: Block explorers — những dữ liệu block, giao dịch, tài khoản, hợp đồng và token mà trình khám phá block có thể hiển thị.
• Ethereum.org: Verifying smart contracts — khác biệt giữa việc khớp mã nguồn, mã máy và kiểm chứng hình thức.
• OpenZeppelin Docs: Upgrades Plugins FAQ — quan hệ giữa proxy, hợp đồng triển khai và người quản trị nâng cấp.
• OpenZeppelin Docs: Preparing for mainnet — kiểm toán, xác thực mã nguồn, quyền quản trị và giới hạn của kiểm toán.
• GitHub Docs: Using the activity view — bản ghi thay đổi, đẩy mã, gộp nhánh và hoạt động nhánh của kho mã.