Phát triển Smart Contract cho Sản phẩm Web3

Khi nào sản phẩm Web3 cần một smart contract tùy chỉnh?

Một smart contract tùy chỉnh hữu ích khi các quy tắc trên chuỗi của sản phẩm không thể được thể hiện chỉ bằng một triển khai token cơ bản. Điều đó có thể bao gồm vesting có kiểm soát, cơ chế staking hoặc một contract kết nối quy trình dApp với các hành động trên chuỗi đã xác định. Quyết định đầu tiên không phải là tính năng nào nghe có vẻ hấp dẫn; mà là quy tắc nào phải được thực thi trên chuỗi và quy tắc nào thuộc về ứng dụng hoặc hoạt động dự án.

Trước khi yêu cầu xây dựng, hãy viết ra:

• Ai có thể khởi tạo mỗi hành động, và ai có thể phê duyệt hoặc quản trị nó.
• Người dùng có thể nạp, yêu cầu, rút hoặc thay đổi những gì.
• Những điều kiện nào phải được đáp ứng trước khi một hành động được phép.
• Điều gì sẽ xảy ra trong trường hợp ngoại lệ hoặc tranh chấp.

Những câu trả lời này trở thành điểm khởi đầu cho một đặc tả kỹ thuật. Nếu công việc cũng bao gồm giao diện xung quanh, hãy căn chỉnh phạm vi contract với phát triển dApp. Nếu contract là một phần của hệ thống lớn hơn, kế hoạch phát triển Web3 tổng thể giúp xác định các thành phần nào phải được giao cùng nhau. Sự tách biệt này giúp dễ dàng ước tính contract và xác định các quyết định sản phẩm vẫn cần chủ sở hữu trước khi bắt đầu viết mã.

Làm thế nào để xác định hành vi contract vesting và staking?

Chúng tôi xác định vesting và staking như các quy tắc hiển thị với người dùng trước khi chuyển chúng thành logic contract. Đặc tả nên mô tả mỗi hành động được phép, điều kiện tiên quyết, thay đổi trạng thái liên quan và những gì người dùng có thể mong đợi thấy sau đó. Điều này cung cấp cho nhóm dự án một cơ sở cụ thể để xác nhận hành vi trước khi triển khai và kiểm thử.

Đối với công việc liên quan đến token, hãy xác nhận các quyết định về nguồn cung và phân bổ với những người chịu trách nhiệm về sản phẩm trước khi triển khai. Dịch vụ tạo và triển khai token của chúng tôi có thể được xem xét khi triển khai là một phần của phạm vi đó. Đối với mọi tính năng, hãy yêu cầu nhóm đánh giá cả đường dẫn thông thường và các trường hợp có thể thay đổi quyền truy cập của người dùng, chẳng hạn như thao tác tạm dừng hoặc thay đổi quản trị. Việc đánh giá đó giúp phát hiện các kỳ vọng không khớp trong khi các thay đổi vẫn là một phần của đặc tả, thay vì sau khi mã được coi là hoàn thiện.

Phát triển smart contract bao gồm những gì?

Phát triển smart contract bao gồm một tập hợp các sản phẩm bàn giao kỹ thuật đã thống nhất, không chỉ là một tệp mã. Gói chính xác được thiết lập trong quá trình xác định phạm vi để nhóm của bạn biết nó sẽ nhận được gì, phải cung cấp gì và điểm bàn giao nằm ở đâu.

Một dự án có thể bao gồm:

• Mô tả bằng văn bản về hành vi và giả định của contract.
• Triển khai contract cho các yêu cầu đã thống nhất.
• Các bài kiểm thử ánh xạ tới các hành động người dùng dự kiến và các trường hợp ngoại lệ đã chọn.
• Phiên bản sẵn sàng để đánh giá và ghi chú cho phối hợp audit, nếu được yêu cầu.
• Hỗ trợ triển khai và chi tiết bàn giao khi triển khai nằm trong phạm vi.

Nếu bạn đang xây dựng một token, hãy làm rõ liệu việc tạo token là một luồng công việc riêng biệt hay một phần của cùng một lần bàn giao. Nếu có một bộ sưu tập liên quan, hãy căn chỉnh yêu cầu contract với phát triển bộ sưu tập NFT để hành vi trên chuỗi và trải nghiệm sản phẩm được xác định phạm vi cùng nhau. Trong quá trình khởi động, Bitcoin Insider sử dụng danh sách kiểm tra yêu cầu để nắm bắt vai trò, quyền hạn, luồng người dùng, phụ thuộc và các quyết định còn bỏ ngỏ. Bạn có thể sử dụng danh sách kiểm tra đó để thu thập thông tin đầu vào từ sản phẩm, kỹ thuật và vận hành trước khi công việc bắt đầu. Các sản phẩm bàn giao đã thống nhất sau đó được ghi lại trong phạm vi, giúp dễ dàng đánh giá tiến độ dựa trên các hành vi cụ thể thay vì các nhãn rộng như “hoàn thành” hoặc “an toàn”.

Dự án smart contract di chuyển từ bản tóm tắt đến bàn giao như thế nào?

Một dự án smart contract di chuyển qua các quyết định, triển khai và đánh giá theo một trình tự giữ cho các yêu cầu sản phẩm luôn hiển thị. Lịch trình được thống nhất sau khi nhóm hiểu được số lượng hành vi contract, phụ thuộc bên ngoài và người tham gia đánh giá; không có thời hạn cố định nào được giả định trước khi phạm vi đó rõ ràng.

Trình tự làm việc là:

1. Khởi động: thu thập danh sách kiểm tra, bối cảnh sản phẩm và người ra quyết định.
2. Đặc tả: thống nhất về vai trò, hành động, thay đổi trạng thái và loại trừ.
3. Triển khai: xây dựng contract trong phạm vi và giữ các câu hỏi gắn với đặc tả.
4. Kiểm thử và đánh giá: so sánh hành vi dự kiến với kết quả kiểm thử và chuẩn bị tài liệu cho bất kỳ audit độc lập nào.
5. Bàn giao: chia sẻ mã đã thống nhất, ghi chú và trách nhiệm triển khai.

Tại Bitcoin Insider, bước đánh giá bao gồm xem xét các yêu cầu so với kế hoạch kiểm thử, sau đó ghi lại các quyết định chưa được giải quyết cho chủ sở hữu dự án. Điều này cung cấp cho cả hai bên một điểm kiểm tra thực tế trước khi một phiên bản được coi là sẵn sàng để bàn giao. Để giữ cho trình tự đó diễn ra, hãy chỉ định một người có thể xác nhận hành vi sản phẩm, cung cấp bất kỳ tài liệu kỹ thuật hiện có nào và tổng hợp phản hồi. Nếu ứng dụng đang được xây dựng song song, hãy phối hợp giao diện contract với nhóm dApp sớm để các câu hỏi tích hợp được đưa ra trong quá trình triển khai, không để đến cuối.

Kế hoạch kiểm thử và audit contract nên thiết lập những gì?

Một kế hoạch kiểm thử nên cho thấy việc triển khai được kiểm tra như thế nào so với các hành vi mà nhóm đã đồng ý xây dựng. Nó hữu ích nhất khi mỗi hành động quan trọng của người dùng có một kết quả dự kiến và khi người đánh giá có thể truy ngược một bài kiểm thử về một yêu cầu. Điều này giúp nhóm của bạn đánh giá xem phạm vi đã giao có khớp với các quy tắc sản phẩm dự định hay không.

Một đánh giá kiểm thử có thể bao gồm các luồng thông thường, quyền truy cập, thay đổi trạng thái và các trường hợp ngoại lệ đã chọn được xác định cho dự án. Đối với một audit độc lập, chúng tôi phối hợp phạm vi, tài liệu đánh giá và theo dõi các phát hiện; nhóm dự án nên quyết định ai sẽ giải quyết vấn đề và phê duyệt thay đổi. Giữ một bản ghi về phiên bản contract đã được đánh giá, các câu hỏi vẫn còn bỏ ngỏ và các quyết định được đưa ra sau khi đánh giá.

Một audit là đánh giá một phiên bản và phạm vi đã xác định, không phải bằng chứng rằng mọi vấn đề có thể đã được tìm thấy. Kết quả cuối cùng cũng phụ thuộc vào phát hiện của người đánh giá bên ngoài và hành vi của mạng đã chọn, vì vậy cả phối hợp đánh giá và kiểm thử đều không thể chứng nhận hoạt động không có rủi ro. Cam kết của chúng tôi là đối với công việc phát triển và phối hợp đã thống nhất, với trạng thái đánh giá và các mục còn bỏ ngỏ được hiển thị cho nhóm của bạn.

Làm thế nào để smart contract phù hợp với phần còn lại của bản dựng Web3 của bạn?

Một contract nên được xác định phạm vi cùng với các thành phần sản phẩm gọi nó, giải thích nó hoặc phụ thuộc vào hành vi của nó. Điều đó không có nghĩa là mọi dự án đều cần một bản dựng kết hợp duy nhất; nó có nghĩa là chủ sở hữu và giao diện nên được xác định đủ sớm để tránh khoảng trống giữa các nhóm.

Sử dụng bản đồ bàn giao này khi lập kế hoạch công việc liên quan:

• Quy tắc và triển khai token: quyết định quyết định token nào là đầu vào cho phát triển contract và quyết định nào là sản phẩm bàn giao riêng biệt.
• Giao diện người dùng: ghi lại các hành động mà ứng dụng phải trình bày và các phản hồi contract mà nó phải xử lý.
• Thông tin sản phẩm: đảm bảo trang web mô tả các hành động và điều kiện của người dùng một cách nhất quán với đặc tả.
• Quyền sở hữu vận hành: xác định ai sẽ xử lý quản trị, theo dõi và các yêu cầu thay đổi trong tương lai sau khi bàn giao.

Nếu một token là trung tâm của sản phẩm, hãy phối hợp bản dựng với tạo và triển khai token. Đối với ứng dụng mà người dùng tương tác, hãy xem xét phát triển dApp; đối với thông tin dự án và giới thiệu, hãy căn chỉnh với phát triển trang web và landing page Web3. Gửi cho Bitcoin Insider bản tóm tắt sản phẩm hiện tại của bạn, ưu tiên chuỗi nếu đã quyết định, và bất kỳ yêu cầu hoặc mã hiện có nào. Chúng tôi sẽ xem xét các tài liệu đó với danh sách kiểm tra khởi động, xác định các quyết định sản phẩm chưa được giải quyết và trả lại một phạm vi contract đề xuất để nhóm của bạn xác nhận.

Bảng giá

Giá khởi điểm bằng USD. Gói tùy chỉnh và chiết khấu theo số lượng theo yêu cầu. Thanh toán bằng USDT, USDC, BTC, ETH, SOL, TON hoặc token dự án của bạn.

Cách hoạt động

1. Chia sẻ bối cảnh sản phẩmGửi trường hợp sử dụng, luồng người dùng và bất kỳ contract hoặc tài liệu kỹ thuật hiện có nào. Ghi chú những quyết định nào vẫn còn bỏ ngỏ.
2. Xác nhận yêu cầuChúng tôi ánh xạ vai trò, hành động, quyền hạn và kết quả dự kiến thành một đặc tả để nhóm của bạn xem xét.
3. Xây dựng phạm vi đã thống nhấtTriển khai theo hành vi đã xác nhận, với các câu hỏi và thay đổi phạm vi được đưa ra để quyết định khi chúng phát sinh.
4. Đánh giá hành vi và phát hiệnChúng tôi làm việc thông qua kế hoạch kiểm thử và, khi được bao gồm, phối hợp tài liệu đánh giá và theo dõi với một kiểm toán viên độc lập.
5. Hoàn tất bàn giaoBạn nhận được các sản phẩm bàn giao đã thống nhất và một bản ghi rõ ràng về trách nhiệm triển khai, trạng thái đánh giá và các quyết định còn lại.