Cách viết whitepaper crypto: biến thông tin dự án thành tài liệu dễ đọc

Phần mở đầu nên cho phép người đọc xác minh điều gì?

Một câu mục đích duy nhất cung cấp cho người đọc một bài kiểm tra cho toàn bộ tài liệu. Nó nên xác định dự án, đối tượng đọc dự kiến, và quyết định hoặc sự hiểu biết mà tài liệu hỗ trợ. Giữ mục đích đó cụ thể cho sản phẩm, không phải là một lời hứa rộng về thị trường.

Trước khi soạn thảo, chọn người đọc chính. Một nhà phát triển có thể cần hành vi thành phần và các giả định tích hợp. Một người dùng tiềm năng có thể cần luồng sản phẩm và các giới hạn hiện tại của nó. Một người nắm giữ token có thể cần các chức năng token được ghi chép và quy tắc quản trị. Tài liệu có thể phục vụ nhiều nhóm, nhưng hãy nêu tên đối tượng đầu tiên và sắp xếp chi tiết theo đó.

Xây dựng một ghi chú ngắn với 4 câu hỏi sau:

• Dự án giải quyết vấn đề gì và cho ai?
• Người dùng hoặc nhà phát triển có thể làm gì hôm nay?
• Những khả năng nào vẫn còn được đề xuất hoặc đang phát triển?
• Người đọc nên có thể đánh giá điều gì sau khi đọc?

Đánh dấu mỗi câu trả lời là đang hoạt động, đã thử nghiệm, đã lên kế hoạch hoặc chưa giải quyết. Từ vựng trạng thái đó giúp ngăn một mục lộ trình đọc như một tính năng có sẵn. Nếu dự án còn sớm, hãy nêu rõ những gì vẫn chưa biết. Sau đó sử dụng tuyên bố mục đích để loại bỏ các đoạn không giúp người đọc được nêu tên hiểu hoặc đánh giá dự án.

Những phần nào nên có trong bản đồ tài liệu của sách trắng?

Một dàn ý 7 phần có thể đưa người đọc từ vấn đề dự án đến các câu hỏi mở của nó. Coi nó như một bản đồ làm việc, không phải một mẫu bắt buộc. Chỉ thêm một phần khi nó giải thích điều gì đó quan trọng về dự án này.

Một trình tự hữu ích là:

• Tóm tắt: vấn đề, cách tiếp cận và tình trạng phát triển hiện tại.
• Vấn đề và bối cảnh: ai gặp vấn đề và những cách tiếp cận hiện có để lại điều gì chưa giải quyết.
• Sản phẩm hoặc giao thức: các thành phần, luồng người dùng và ranh giới hệ thống.
• Thiết kế kỹ thuật: kiến trúc liên quan, phụ thuộc và giả định bảo mật.
• Thiết kế token, nếu có: chức năng, quy tắc cung ứng, phân bổ và cơ chế quản trị.
• Lộ trình và trách nhiệm: công việc đã lên kế hoạch, chủ sở hữu quyết định và phụ thuộc.
• Rủi ro và câu hỏi mở: giới hạn đã biết và các lựa chọn thiết kế chưa giải quyết.

Không thêm kinh tế token vào một dự án không có token. Đối với một dự án có token, không chôn cơ chế cốt lõi trong phụ lục. Đặt giải thích ngắn trước chi tiết chuyên môn. Sử dụng phụ lục cho tài liệu hỗ trợ một tuyên bố nhưng làm gián đoạn giải thích chính.

Đối với kế hoạch launch mở rộng ngoài tài liệu, hãy xem danh sách kiểm tra launch token. Giữ các thông tin dự án của nó phù hợp với sách trắng. Để có tổng quan riêng về chuẩn bị listing, hãy tham khảo hướng dẫn về listing CoinMarketCap và listing CoinGecko. Các tài nguyên đó giải quyết các nhiệm vụ khác nhau; chúng không nên được sử dụng làm bằng chứng rằng một dự án đáp ứng yêu cầu của một nền tảng.

Làm thế nào người đọc có thể truy xuất một tuyên bố đến nguồn của nó?

Một danh sách tuyên bố cho thấy những phát biểu nào cần xác minh trước khi văn xuôi được trau chuốt. Tạo một danh sách cho mọi tuyên bố quan trọng về hành vi sản phẩm, cơ chế token, giả định bảo mật hoặc trạng thái dự án. Bản ghi làm cho các lỗ hổng hiện ra trong khi bản nháp vẫn dễ thay đổi.

Sử dụng 4 trường cho mỗi mục: tuyên bố chính xác, nguồn hoặc giả định đã nêu, trạng thái và người xem xét. Quy trình xem xét mặc định của chúng tôi sử dụng 3 điểm kiểm tra: khớp nguồn, khớp trạng thái và phê duyệt của chủ sở hữu. Một hướng dẫn sử dụng sản phẩm có thể hỗ trợ mô tả luồng người dùng. Một bản ghi thiết kế có thể giải thích quyết định kiến trúc. Một dự báo nên được xác định là ước tính, không được trình bày như một kết quả quan sát được. Nếu không có tài liệu hỗ trợ, hãy định tính tuyên bố hoặc loại bỏ nó.

Các đoạn về token cần định nghĩa chính xác. Giải thích từng thuật ngữ cung ứng có nghĩa là gì và quy tắc phân bổ hoặc phát hành hoạt động như thế nào. Xác định quy tắc nào được ghi chép và quy tắc nào có thể thay đổi thông qua quản trị hoặc một quy trình đã nêu khác. Không ngụ ý rằng việc nắm giữ token mang lại quyền lợi trừ khi các điều khoản của dự án hỗ trợ cách đọc đó.

Bản ghi này cũng giúp các biên tập viên tương lai tìm thấy văn bản bị ảnh hưởng bởi thay đổi sản phẩm. So sánh các mục của nó với tài liệu hiện tại của dự án và với danh sách kiểm tra launch token. Tại GeoMarketing Experts, người xem xét có thể trả lại bản nháp đã đánh dấu với các câu hỏi được nhóm theo chủ sở hữu. Đối với một hợp đồng viết, hãy xem dịch vụ viết whitepaper và litepaper; đối với phạm vi công việc trả phí, hãy xem giá dịch vụ viết sách trắng crypto.

Bao nhiêu chi tiết kỹ thuật nên có trong tài liệu chính?

Một sơ đồ hệ thống và chú thích của nó nên kể cùng một câu chuyện như văn xuôi. Sử dụng chi tiết kỹ thuật để cho thấy các thành phần tương tác như thế nào và hành vi của chúng dựa trên những giả định nào. Một danh sách các chuỗi, hợp đồng hoặc thuật ngữ mật mã là không đủ nếu không có các mối quan hệ đó.

Bắt đầu với tổng quan hệ thống bằng ngôn ngữ đơn giản. Sau đó giải thích từng thành phần quan trọng theo vai trò, đầu vào, đầu ra và phụ thuộc của nó. Đối với một quy trình nhiều tác nhân, hãy xác định ai bắt đầu hành động, hệ thống kiểm tra những gì và điều gì xảy ra khi một phụ thuộc không khả dụng. Định nghĩa các thuật ngữ chuyên môn ở lần sử dụng đầu tiên. Giữ một thuật ngữ gắn với một nghĩa trong suốt tài liệu.

Sử dụng sơ đồ để hiển thị luồng, ranh giới tin cậy hoặc chuyển động dữ liệu. Thêm chú thích nêu tên những gì hình vẽ bao gồm và bỏ qua. Một sơ đồ không nên gợi ý rằng một quy trình ngoài chuỗi được thực thi bởi một hợp đồng thông minh. Liên kết đến tài liệu kỹ thuật sâu hơn khi người đọc cần chi tiết triển khai ngoài mục đích của tài liệu.

Thực hiện 2 kiểm tra trên mỗi sơ đồ quan trọng: xác nhận nhãn của nó khớp với văn bản, sau đó yêu cầu người xem xét kỹ thuật xác minh hành vi được mô tả. Ghi lại 4 trường cho mỗi sơ đồ: mục đích, thành phần, ranh giới và người xem xét. Đánh dấu các thành phần là đã thử nghiệm, đã audit hoặc được đề xuất chỉ khi bằng chứng dự án hỗ trợ nhãn. Những mô tả đó không thể thay thế cho nhau. Nếu thiết kế đang thay đổi, hãy xác định chi tiết nào là tạm thời thay vì viết chúng như sự thật đã được xác lập.

Những kiểm tra biên tập nào phát hiện lỗ hổng trong sách trắng crypto?

Một mâu thuẫn giữa mô tả token và lộ trình là một lỗi nội dung, không phải vấn đề phong cách. Xem xét trạng thái, định nghĩa và bằng chứng trước khi dành thời gian trau chuốt câu. Các kiểm tra này làm cho bản nháp dễ đánh giá hơn:

• Lời hứa không có cơ chế: mô tả hệ thống và các phụ thuộc của nó thay vì khẳng định một kết quả.
• Kế hoạch được viết như bàn giao: gắn nhãn công việc tương lai và phân biệt nó với chức năng có sẵn.
• Chức năng token mơ hồ: giải thích token làm gì trong hệ thống.
• Số liệu hoặc thuật ngữ không xác định: nói rõ mỗi giá trị hoặc nhãn đề cập đến cái gì.
• Từ vựng kỹ thuật không có ngữ cảnh: định nghĩa một thuật ngữ và giải thích tại sao nó quan trọng.
• Tên hoặc quy tắc xung đột: so sánh mô tả cung ứng, vai trò quản trị và nhãn trạng thái giữa các phần.
• Đoạn chung chung: loại bỏ ngôn ngữ không mô tả thiết kế hoặc trách nhiệm của dự án này.

Đối với mỗi phần, hãy hỏi người đọc cẩn thận có thể xác minh điều gì từ nội dung của nó. Thêm nguồn, định tính một giả định hoặc sửa đổi tuyên bố khi câu trả lời không rõ ràng. Sau đó thực hiện một lượt biên tập riêng cho trình tự và khả năng đọc. Giữ việc kiểm tra thông tin tách biệt với biên tập bản sao giúp giảm nguy cơ từ ngữ mượt mà hơn che giấu một tuyên bố chưa được giải quyết.

Người xem xét nên ghi lại các thay đổi như thế nào trước khi phát hành?

Một nhật ký thay đổi cung cấp cho nhóm một bản ghi về những gì đã thay đổi và tại sao. Phân công xem xét theo chủ đề: kỹ sư kiểm tra mô tả hệ thống, chủ sở hữu token kiểm tra cơ chế, và người xem xét biên tập kiểm tra cấu trúc và tính nhất quán. Cố vấn nên xem xét ngôn ngữ cần đánh giá pháp lý.

Sử dụng trình tự này:

• Đóng băng dàn ý và thu thập các tài liệu nguồn hiện tại.
• Soạn thảo các giải thích và ánh xạ các tuyên bố tài liệu đến bằng chứng.
• Chuyển từng tuyên bố đến người chịu trách nhiệm kiểm tra nó.
• Giải quyết các bình luận và ghi lại lý do cho các thay đổi quan trọng.
• Kiểm tra liên kết, sơ đồ, thuật ngữ và nhãn phiên bản so với văn bản cuối cùng.

Một tài liệu được đánh dấu với các câu hỏi được nhóm theo chủ sở hữu cung cấp cho bản sửa đổi tiếp theo một lộ trình rõ ràng. Nó giúp các founder giải quyết phạm vi và trạng thái, trong khi người xem xét kỹ thuật tập trung vào mô tả hệ thống. Giữ nhật ký thay đổi cho đến khi xuất bản để người xem xét có thể thấy tuyên bố nào đã di chuyển và tại sao.

Đối với truyền thông dự án ngoài sách trắng, hãy so sánh tài liệu với hướng dẫn marketing crypto và tài liệu kỹ thuật hiện tại của dự án. Không sử dụng một trong hai như một sự thay thế cho việc kiểm tra thông tin nguồn. Tại GeoMarketing Experts, quy trình xem xét bản nháp ánh xạ các tuyên bố tài liệu đến bằng chứng của chúng và trả lại câu hỏi theo chủ sở hữu. Gửi dàn ý hiện tại, tài liệu sản phẩm, tài liệu token nếu có và bất kỳ tuyên bố nào cần xem xét để thảo luận hỗ trợ viết whitepaper.

Một sách trắng đã xuất bản để lại điều gì chưa được chứng minh?

Một nhãn phiên bản và chủ sở hữu được chỉ định giúp người đọc xác định họ đang đọc tài liệu nào. Giữ một lộ trình từ tài liệu đến tài liệu dự án hiện tại. Xem xét tài liệu khi một tính năng quan trọng, quy tắc token, quy trình quản trị hoặc trạng thái dự án thay đổi. Nếu nó không còn phản ánh dự án, hãy cập nhật nó hoặc đánh dấu nó là lỗi thời.

Một tài liệu chính thức không thể xác lập rằng một triển khai hoạt động như được mô tả hoặc chứng nhận bảo mật. Các điều khoản token và quản trị cũng vẫn tuân theo các quy tắc đã được ghi chép của dự án. Nêu các giả định và phụ thuộc chưa giải quyết trong tài liệu, sau đó tìm kiếm đánh giá kỹ thuật và pháp lý có thẩm quyền cho các câu hỏi mà các tài liệu đó không thể giải quyết.

Trước khi xuất bản, kiểm tra rằng văn bản cuối cùng đồng ý với sản phẩm và các tài liệu quản trị. Xác nhận rằng sơ đồ, thuật ngữ, nhãn phiên bản và liên kết khớp với bản nháp đã xem xét. Giao trách nhiệm cho một thành viên nhóm được nêu tên cho các bản cập nhật trong tương lai thay vì cho rằng tài liệu sẽ tự động duy trì hiện tại.

Để bắt đầu một bản nháp, hãy thu thập dàn ý, tài liệu sản phẩm hiện tại, tài liệu token nếu có và danh sách các tuyên bố cần xem xét. Gửi những mục đó đến GeoMarketing Experts. Bước tiếp theo là kiểm tra tuyên bố với nguồn, sau đó là danh sách lỗ hổng cho những người chịu trách nhiệm giải quyết từng câu hỏi.

Cách hoạt động

1. Xác định người đọc và mục đíchNêu tên đối tượng chính và những gì tài liệu nên giúp họ đánh giá. Tách nhiệm vụ đó khỏi marketing, điều khoản pháp lý và tài liệu kỹ thuật chi tiết.
2. Thu thập và gắn nhãn thông tin hiện tạiThu thập tài liệu sản phẩm, kiến trúc, token và lộ trình. Đánh dấu mỗi mục là đang hoạt động, đã thử nghiệm, đã lên kế hoạch hoặc chưa giải quyết.
3. Ánh xạ các phần và tuyên bốSắp xếp dàn ý xung quanh nhu cầu của người đọc. Ghi lại nguồn và người xem xét cho mỗi tuyên bố quan trọng.
4. Soạn thảo giải thíchGiải thích hệ thống bằng ngôn ngữ đơn giản trước khi thêm chi tiết triển khai. Chú thích sơ đồ và xác định giới hạn của chúng.
5. Xem xét và duy trì tài liệuChuyển các tuyên bố đến đúng người xem xét, giải quyết mâu thuẫn và chỉ định chủ sở hữu cho các bản cập nhật trong tương lai.