스마트 컨트랙트 개발, 코드 작성 전 검증 완료

첫 번째 컨트랙트 검토는 무엇을 비교합니까?

1회 사전 검증은 보내신 규칙과 컨트랙트가 실행해야 하는 동작을 비교합니다. 구현 전에 누락된 결정을 식별한 후, 어떤 작업이 온체인에 속하는지 합의합니다.

표는 하나의 프로젝트에 포함될 수 있는 4가지 작업 영역을 구분합니다. 귀하의 규칙이 적용 여부를 결정합니다. 하나의 컨트랙트는 하나의 기능을 수행할 수 있습니다. 연결된 컨트랙트는 더 많은 인터페이스 결정이 필요합니다.

각 작업에 대해 시작 주체, 적용 조건, 변경 사항을 기록합니다. 또한 거부된 작업과 예상 사용자 결과를 기록합니다. 이를 통해 팀은 코드가 가정을 컨트랙트 동작으로 전환하기 전에 구체적인 검토를 할 수 있습니다.

토큰이 설계에 포함된 경우, 이 작업을 토큰 생성 및 배포와 연결하십시오.

컨트랙트 결정을 투명하게 유지하는 7가지 입력

7가지 입력은 컨트랙트 사양의 실질적인 출발점을 제공합니다. 보유한 자료를 보내주시고, 답변되지 않은 항목은 추측을 승인된 규칙으로 취급하지 말고 표시해 주십시오.

• 제품 목적: 컨트랙트가 수행해야 하는 작업.
• 사용자 흐름: 진입부터 완료까지의 작업.
• 역할: 사용자, 관리자 및 각각 필요한 권한.
• 비즈니스 규칙: 조건, 시기, 예외 사례.
• 네트워크 선호도: 이미 선택한 경우 대상 네트워크.
• 인터페이스: 기존 컨트랙트 및 애플리케이션 요구 사항.
• 검토 필요 사항: 알려진 운영, 법률 또는 감사 요구 사항.

베스팅의 경우 다음을 포함하십시오:

• 할당 출처, 수혜자, 시작 조건.
• 릴리스 패턴 및 청구 프로세스.
• 일정을 변경할 수 있는 사람과 해당 작업을 승인할 수 있는 사람.

스테이킹의 경우 다음을 기록하십시오:

• 예치 및 출금 단계.
• 보상 입력 및 청구 규칙.
• 일시 중지 동작.

검토에서 종속성과 미결정 사항을 표시합니다. 그런 다음 팀이 승인 기준을 승인하도록 요청합니다. 해당 승인은 구현에 명확한 기준을 제공합니다.

작업이 컨트랙트 코드를 넘어 확장되는 경우, Web3 개발이 더 넓은 제품을 다룰 수 있습니다. dApp 개발은 애플리케이션 계층을 다룹니다.

규칙에서 릴리스까지 3가지 작업 기간

3가지 작업 기간은 제품 결정, 코드, 릴리스 준비를 구분합니다. 정확한 일정은 합의된 컨트랙트 동작, 통합 및 검토 필요 사항에 따라 결정됩니다.

1. 규칙 기간: 역할, 작업, 조건, 예외 사례를 매핑합니다. 팀이 컨트랙트 동작에 영향을 미치는 결정을 해결합니다.
2. 사양 기간: 승인된 동작과 승인 기준을 기록합니다. 구현 시작 전에 문서를 검토합니다.
3. 빌드 기간: 합의된 컨트랙트 로직을 구현합니다. 코드는 검토된 사양과 일치하도록 유지합니다.
4. 테스트 기간: 예상 경로, 권한, 유효하지 않은 입력, 지정된 예외 사례를 확인합니다. 발견 사항과 해결되지 않은 제품 선택 사항은 검토를 위해 기록됩니다.
5. 릴리스 기간: 구성 노트와 인계 세부 정보를 준비합니다. 독립적인 검토가 포함된 경우, 해당 자료와 질문을 조정합니다.

각 기간은 가정된 승인이 아닌 검토 가능한 산출물 또는 결정으로 종료됩니다. 준비된 것과 응답이 필요한 것을 확인할 수 있습니다. 연결된 제품의 경우, 애플리케이션 통합을 담당하는 팀을 확인하십시오. 또한 사용할 컨트랙트 인터페이스를 확인하십시오.

컨트랙트 테스트와 감사가 알려줄 수 있는 것은 무엇입니까?

테스트는 컨트랙트가 사양에 합의된 동작을 따르는지 보여줍니다. 독립적인 감사는 별도의 검토로, 자체 평가와 결과를 가집니다.

각 핵심 동작을 특정 검사와 연결합니다:

• 사용자 작업.
• 권한.
• 유효하지 않은 입력.
• 계획에 포함된 컨트랙트 부분 간 상호 작용.

테스트 실행을 요약하고 미해결 항목을 일반 언어로 기록합니다. 이는 팀이 코드 문제와 여전히 결정이 필요한 제품 규칙을 구분하는 데 도움이 됩니다.

외부 검토를 위해 정확한 소스 버전, 간단한 컨트랙트 흐름 설명, 알려진 가정, 종속성, 테스트 지침을 준비하십시오. 해당 자료를 정리하고, 검토자 질문을 추적하며, 팀이 합의된 수정 사항을 확인하도록 도울 수 있습니다. 개발 테스트와 감사 조정은 검토자의 작업과 별개입니다.

테스트 실행은 배포된 컨트랙트가 모든 네트워크 조건에서 어떻게 동작할지 결정할 수 없습니다. 선택된 감사 제공자가 결과를 통제합니다. 지갑 동작과 타사 통합 역시 당사가 구축하는 컨트랙트 코드 범위 밖에 있습니다. 릴리스 결정 시 사양, 테스트 기록, 검토 결과와 함께 이러한 경계를 유지하십시오.

빌드에서 릴리스로 가져갈 3가지 기록

3가지 기록은 팀에 실용적인 인계를 제공합니다: 승인된 규칙, 테스트 증거, 배포 노트. 작업 시작 전에 내용을 합의하여 팀이 무엇을 기대할지 알 수 있도록 합니다.

• 감사 기록: 감사 작업은 별도로 유지합니다. 외부 감사가 계획에 포함된 경우, 해당 제공자가 평가를 소유하며, 당사는 자료와 응답을 조정합니다.
• 토큰 또는 애플리케이션: 토큰 생성 및 배포 또는 dApp 개발과 인터페이스 결정을 조정하십시오.
• 웹사이트: Web3 웹사이트는 별도의 제품 구성 요소로 계획할 수 있습니다.

DigitalMedia1에서는 구현 전에 규칙과 인터페이스를 확인합니다. 그런 다음 테스트를 해당 승인된 동작에 다시 연결합니다. 제품 브리프, 선호 네트워크, 기존 컨트랙트 자료를 보내주십시오. 검토 후 영업일 기준 2일 이내에 서면 견적을 보내드립니다.

이용 방법

1. 1 — 제품 규칙 보내기시점: 사양 전. 사용자 흐름, 역할, 네트워크 선호도, 기존 코드, 알려진 검토 필요 사항을 보내주십시오.
2. 2 — 컨트랙트 경계 검토시점: 계획 검토. 종속성, 미결정 사항, 승인이 필요한 동작을 식별합니다.
3. 3 — 사양 승인시점: 구현 전. 팀이 역할, 흐름, 예외 사례, 승인 기준을 확인합니다.
4. 4 — 빌드 및 테스트시점: 구현 및 테스트. 합의된 로직을 구축하고 지정된 동작에 대한 검사를 기록합니다.
5. 5 — 인계 준비시점: 릴리스 준비. 배포 노트를 제공하고 포함된 외부 감사 작업을 조정합니다.