Những quyết định hợp đồng nào thuộc về bản ghi phạm vi đầu tiên?
Tạo phẩm đầu tiên là một bản ghi phạm vi, không phải ước tính mã. Nó kết nối mỗi hành động sản phẩm với một tác nhân, quyền hạn và kết quả trên chuỗi dự kiến. Chúng tôi sử dụng 6 trường: tác nhân, hành động, quyền hạn, thay đổi trạng thái, phản hồi lỗi và sự kiện. Các trường này làm lộ các quyết định còn thiếu trước khi triển khai smart contract.
Đối với mỗi chức năng được đề xuất, hãy cung cấp luồng người dùng và kết quả dự kiến. Thêm bất kỳ vai trò quản trị và ràng buộc nào đã biết. Đối với công việc liên quan đến token, hãy bao gồm mô hình token hiện tại hoặc các chức năng dự kiến. Đối với một sản phẩm được kết nối, hãy bao gồm ghi chú giao diện và nhóm chịu trách nhiệm tích hợp.
Bản ghi phạm vi giúp xác định liệu yêu cầu cần một hợp đồng hay nhiều thành phần liên quan. Nó cũng đánh dấu các quyết định cần sự chấp thuận của bạn. Mang các đầu vào này đến buổi xem xét:
- Luồng sản phẩm, bao gồm các hành động bị từ chối hoặc trì hoãn.
- Chuỗi dự kiến và các phụ thuộc hợp đồng đã biết.
- Kỳ vọng về vai trò và quyền hạn.
- Các quy tắc vesting hoặc staking đã được nhóm phê duyệt.
- Điều kiện bàn giao và bất kỳ yêu cầu audit nào.
Đối với các chức năng token, hãy phối hợp phạm vi hợp đồng với tạo và triển khai token. Phạm vi phát triển Web3 rộng hơn có thể bao gồm các thành phần sản phẩm được kết nối.
Làm thế nào một đặc tả trở thành hành vi hợp đồng có thể kiểm thử?
Một đặc tả trở nên có thể kiểm thử khi mọi hành động quan trọng đều có kết quả dự kiến và quyền hạn xác định. Chúng tôi chuyển đổi phạm vi đã phê duyệt thành hành vi mà nhóm sản phẩm và kỹ thuật có thể xem xét trước khi bắt đầu viết mã.
Quá trình đặc tả của chúng tôi kiểm tra 3 lĩnh vực: hành động người dùng, quyền hạn quản trị và ranh giới hợp đồng. Đối với mỗi hành động, chúng tôi ghi lại đầu vào hợp lệ, thay đổi trạng thái kết quả và phản hồi đối với yêu cầu không hợp lệ. Nếu nhóm chưa quyết định một hành vi, chúng tôi liệt kê nó là đang mở thay vì chọn một quy tắc mà không có sự chấp thuận.
Các bài kiểm tra sau đó ánh xạ tới đặc tả. Chúng tôi sử dụng 2 nhóm kiểm thử: luồng dự kiến và đường dẫn lỗi đã xác định. Kiểm thử luồng dự kiến bao gồm các hành động được phép và thay đổi trạng thái. Kiểm thử đường dẫn lỗi bao gồm các hành động bị từ chối, ranh giới vai trò và các điều kiện ngăn cản cập nhật. Các trường hợp cụ thể tuân theo các chức năng và tích hợp của hợp đồng.
Bạn có thể xem xét đặc tả trước khi triển khai và sử dụng nó làm tài liệu tham khảo trong các thay đổi sau này. Đối với các giao diện ứng dụng gọi hợp đồng, hãy căn chỉnh bàn giao với phát triển dApp. Điều đó cung cấp cho cả hai nhóm một mô tả chung về ranh giới hợp đồng.
Các quy tắc vesting và staking cần chỉ rõ những gì?
Một brief vesting hoặc staking cần các quy tắc rõ ràng cho người tham gia, quyền hạn và di chuyển tài sản. Chỉ đặt tên cho tính năng không xác định cách nó hoạt động. Chúng tôi ghi lại các điều kiện trước, sau đó kết nối mỗi điều kiện với một triển khai và trường hợp kiểm thử.
Đối với vesting, xác nhận ai nhận tài sản, khi nào giải ngân xảy ra và liệu có bên được ủy quyền nào có thể thay đổi người thụ hưởng hoặc lịch trình hay không. Đối với staking, xác định hành động gửi và rút, logic phần thưởng và các vai trò có thể ảnh hưởng đến các quy tắc đó. Những lựa chọn này thuộc về dự án. Chúng tôi ghi lại chúng để phê duyệt thay vì nhúng các giả định vào mã.
Sử dụng so sánh này để chuẩn bị thảo luận sản phẩm:
| Lĩnh vực hợp đồng | Quyết định cần ghi chép |
|---|---|
| Vesting | Người thụ hưởng, điều kiện giải ngân và các thay đổi được phê duyệt |
| Staking | Gửi, rút, logic phần thưởng và quyền hạn |
| Quản trị | Vai trò được ủy quyền và các kiểm soát được phép |
Đối với mỗi hàng, hãy hỏi liệu hành vi có thể được mô tả như một đầu vào và kết quả rõ ràng hay không. Nếu không, hãy xác định quyết định sản phẩm vẫn cần thiết. Điều này tạo ra một đặc tả hữu ích hơn và cung cấp cho kế hoạch kiểm thử một tài liệu tham khảo cụ thể.
Những bằng chứng nào đi kèm với mã hợp đồng?
Hồ sơ bàn giao kết nối mã nguồn với đặc tả đã phê duyệt và bằng chứng kiểm thử của nó. Điều này giúp nhóm của bạn dễ dàng xem xét những gì đã được xây dựng và chuẩn bị công việc cho một người xem xét bên ngoài.
Bàn giao có thể bao gồm mã nguồn và tài liệu kho lưu trữ đã thỏa thuận, các bài kiểm tra gắn với các luồng đã chỉ định, ghi chú cấu hình, phụ thuộc và đầu vào triển khai. Chúng tôi cũng ghi lại các giả định chưa được giải quyết cần sự chấp thuận của bạn. Hồ sơ phân biệt công việc đã hoàn thành với các quyết định vẫn đang chờ phản hồi.
Phối hợp audit chuẩn bị bối cảnh liên quan cho một người xem xét độc lập. Chúng tôi có thể tổ chức đặc tả, phiên bản mã nguồn, thông tin kiểm thử và các giả định triển khai. Sau khi các phát hiện đến, chúng tôi giúp kết nối từng mục với yêu cầu hoặc khu vực mã liên quan. Nhóm của bạn phê duyệt bất kỳ thay đổi nào ảnh hưởng đến hành vi sản phẩm, quyền hạn hoặc giả định bàn giao.
Người audit đưa ra đánh giá độc lập. Phối hợp không thay thế đánh giá đó. Đối với các hợp đồng hỗ trợ một ứng dụng, hãy bao gồm ranh giới tương tác trong tài liệu xem xét. Chia sẻ yêu cầu giao diện với nhóm phát triển dApp để bàn giao hợp đồng và ứng dụng sử dụng các giả định nhất quán.
Quá trình xây dựng được theo dõi như thế nào từ tiếp nhận đến bàn giao?
Hồ sơ dự án theo dõi các quyết định qua 5 giai đoạn: tiếp nhận, đặc tả, triển khai, kiểm thử và bàn giao. Mỗi giai đoạn có một tạo phẩm mà nhóm của bạn có thể xem xét. Lịch trình được thống nhất sau khi chúng tôi hiểu ranh giới hợp đồng, tích hợp, nhu cầu phê duyệt và phụ thuộc xem xét bên ngoài.
Ở giai đoạn tiếp nhận, chúng tôi thu thập sở thích chuỗi, luồng người dùng, kỳ vọng vai trò và ghi chú thiết kế hiện có. Trong quá trình đặc tả, nhóm của bạn xác nhận hành vi dự kiến. Triển khai tuân theo phạm vi đã phê duyệt đó. Kiểm thử ghi lại những hành vi và đường dẫn lỗi nào đã được kiểm tra. Bàn giao tập hợp mã nguồn, bằng chứng kiểm thử và ghi chú bàn giao.
Cập nhật tiến độ xác định các mục đã hoàn thành, câu hỏi mở và phê duyệt tiếp theo cần thiết. Nhóm của bạn nên chỉ định một người có thể xác nhận các quy tắc sản phẩm. Điều này tránh việc coi một câu hỏi chưa được trả lời là một yêu cầu đã được phê duyệt. Trước khi bàn giao, chúng tôi so sánh các sản phẩm bàn giao đã thỏa thuận với bản ghi phạm vi và xác định bất kỳ phụ thuộc còn lại nào.
Một hợp đồng kết nối với website hoặc landing page có thể cần lập kế hoạch song song. Xem phát triển website và landing Web3 cho công việc giao diện. Đối với phạm vi kỹ thuật rộng hơn, hãy xem phát triển Web3.
Hồ sơ bàn giao cho thấy điều gì về rủi ro cụ thể của chuỗi?
Hồ sơ bàn giao hiển thị phiên bản mã nguồn đã phê duyệt, bằng chứng kiểm thử, đầu vào cấu hình và trách nhiệm triển khai. Nó cung cấp cho dự án một danh sách kiểm tra cụ thể trước khi ứng viên bàn giao được chuyển đến nhóm vận hành của nó.
Xác nhận rằng chuỗi dự kiến và đầu vào triển khai khớp với phạm vi đã phê duyệt. Xác minh ai sẽ triển khai và quản trị hợp đồng. Kiểm tra rằng phiên bản mã nguồn tương ứng với bằng chứng kiểm thử. Ghi lại bất kỳ phát hiện audit nào vẫn cần quyết định của dự án. Xác nhận giao diện sản phẩm nào phụ thuộc vào địa chỉ hợp đồng kết quả.
Một hợp đồng được bàn giao mà không có cơ chế nâng cấp có thể không thể thay đổi sau đó, và các giao dịch trên chuỗi công khai có thể hiển thị. Xử lý giao dịch mạng và kết luận của một auditor độc lập vẫn nằm ngoài tầm kiểm soát của chúng tôi. Chúng tôi bàn giao mã, bài kiểm tra và tài liệu bàn giao đã thỏa thuận, không phải là sự chấp thuận hay một bàn giao không có lỗi.
Đối với một giao diện Telegram được kết nối, hãy xác định chủ sở hữu và đầu vào hợp đồng của nó cùng với phát triển bot Telegram và mini app. Gửi cho chúng tôi luồng sản phẩm, sở thích chuỗi, ghi chú token hoặc hợp đồng hiện tại và yêu cầu audit. Chúng tôi sẽ xem xét các tài liệu đó, xác định các quyết định còn mở và trả về một kế hoạch phát triển có phạm vi.
Cách hoạt động
- Gửi luồng sản phẩmChia sẻ các hành động người dùng dự kiến, sở thích chuỗi, ghi chú hợp đồng hoặc token hiện có và các ràng buộc bàn giao.
- Xem xét yêu cầuChúng tôi ánh xạ quyền hạn, ranh giới hợp đồng, phụ thuộc và các quyết định sản phẩm chưa được giải quyết với nhóm của bạn.
- Phê duyệt đặc tảBạn xác nhận hành vi và phạm vi đã được ghi chép trước khi triển khai bắt đầu.
- Xây dựng và kiểm thửChúng tôi triển khai các hợp đồng đã thỏa thuận, chuẩn bị bài kiểm tra và báo cáo tiến độ so với phạm vi đã xác nhận.
- Chuẩn bị bàn giaoChúng tôi tổ chức mã nguồn, bằng chứng kiểm thử và ghi chú triển khai, sau đó phối hợp bất kỳ bàn giao audit nào đã thỏa thuận.
Câu hỏi thường gặp
Chúng tôi nên gửi gì trước buổi xem xét hợp đồng đầu tiên?
Gửi một luồng sản phẩm, chuỗi dự kiến và bất kỳ ghi chú token hoặc hợp đồng hiện có nào. Bao gồm kỳ vọng về vai trò, quy tắc vesting hoặc staking, yêu cầu giao diện và điều kiện bàn giao nếu có. Bản ghi phạm vi 6 trường của chúng tôi ghi lại hành động, quyền hạn và kết quả dự kiến. Các quyết định còn thiếu trở thành mục xem xét thay vì giả định ẩn.
Một hợp đồng tùy chỉnh có thể bao gồm cả vesting và staking không?
Nó có thể được phạm vi theo cách đó nếu yêu cầu sản phẩm và ranh giới hợp đồng hỗ trợ. Chúng tôi ghi lại người thụ hưởng vesting và điều kiện giải ngân riêng biệt với gửi, rút và quy tắc phần thưởng staking. Đặc tả sau đó cho thấy các luồng đó tương tác ở đâu. Nhóm của bạn xác nhận hành vi trước khi triển khai và kiểm thử.
Phối hợp audit có nghĩa là nhóm của bạn thực hiện audit không?
Không. Phối hợp audit chuẩn bị mã nguồn, đặc tả và thông tin kiểm thử cho một người xem xét độc lập. Chúng tôi có thể giúp tổ chức các phát hiện và theo dõi công việc tiếp theo đã thỏa thuận. Người xem xét cung cấp đánh giá. Hồ sơ bàn giao xác định phát hiện nào vẫn còn mở, có phản hồi được đề xuất hoặc cần quyết định của dự án.
Điều gì ảnh hưởng đến lịch trình cho một bản build hợp đồng tùy chỉnh?
Tiến độ được xác định sau khi xem xét phạm vi. Số lượng thành phần hợp đồng, độ phức tạp của quy tắc, tích hợp và chu kỳ phê duyệt định hình kế hoạch. Lịch trình audit bên ngoài cũng có thể ảnh hưởng đến trình tự bàn giao. Khi các đầu vào đó rõ ràng, chúng tôi đặt các mốc cho đặc tả, triển khai, kiểm thử và tài liệu bàn giao.
Nhóm có thể sửa đổi hành vi hợp đồng sau khi triển khai không?
Điều đó phụ thuộc vào thiết kế được phê duyệt trước khi bàn giao. Một hợp đồng không có cơ chế nâng cấp có thể không thể thay đổi sau đó. Một thiết kế có thể nâng cấp yêu cầu các quyết định về quyền hạn và phê duyệt thay đổi. Chúng tôi ghi lại cách tiếp cận dự kiến trong đặc tả để nhóm của bạn có thể xem xét hậu quả vận hành trước khi triển khai.
Bạn có thể đảm bảo một auditor độc lập sẽ phê duyệt mã của chúng tôi không?
Không. Auditor kiểm soát phương pháp xem xét, phát hiện và kết luận của họ. Chúng tôi có thể chuẩn bị một gói xem xét rõ ràng, phối hợp bàn giao và giúp nhóm của bạn phản hồi các phát hiện. Công việc phát triển đã thỏa thuận vẫn là mã nguồn, bài kiểm tra và tài liệu bàn giao được liệt kê trong phạm vi.
Kể cho chúng tôi về dự án của bạn
Trả lời bốn câu hỏi nhanh và quản lý sẽ gửi kế hoạch, thời gian và mức giá trong vòng một giờ. Mọi thứ được bảo mật.
Đang tải biểu mẫu…