스마트 컨트랙트 개발은 무엇을 포함하나요?
스마트 컨트랙트 개발은 귀사의 제품 규칙을 검토, 테스트 및 배포 준비가 가능한 컨트랙트 동작으로 전환합니다. 토큰, 애플리케이션, 베스팅 약정, 스테이킹 기능 또는 기타 정의된 온체인 워크플로우를 위한 컨트랙트가 필요한 팀에 적합합니다.
- 맞춤형 컨트랙트: 사용자 액션, 권한 및 상태 변경을 문서화된 범위로 변환합니다.
- 베스팅: 할당을 받는 대상, 사용 가능 시점 및 허용되는 액션을 정의합니다.
- 스테이킹: 참여 흐름과 컨트랙트가 적용해야 하는 규칙을 문서화합니다.
- 감사 조정: 외부 검토를 위한 구현체 및 지원 자료를 준비합니다.
사용자가 수행할 수 있는 작업, 관리자가 변경할 수 있는 사항, 그리고 절대 발생해서는 안 되는 결과를 설명하는 것으로 시작하세요. 기존 컨트랙트나 제품 의존성이 있다면 이를 명시하세요. 이 정보는 컨트랙트 로직을 인터페이스나 백엔드 작업과 분리하는 데 도움이 됩니다. 컨트랙트가 더 큰 빌드의 일부라면 Web3 개발 또는 dApp 개발과 연결하세요. 아직 구체화되지 않은 토큰의 경우, 구현 전에 토큰 생성 및 배포와 컨트랙트 범위를 조정하세요.
AEOTech는 합의된 동작과 제외 사항을 Launch Spec에 기록합니다. 이를 통해 코드가 작성되기 전에 제품 및 엔지니어링 이해관계자가 공유 기준을 가질 수 있습니다.
코딩 전에 컨트랙트 동작을 어떻게 정의하나요?
유용한 컨트랙트 명세는 단순한 기능 이름이 아닌 관찰 가능한 동작을 설명합니다. 귀사의 요구사항을 명시적인 액션, 권한 및 예외 상황으로 전환하여 팀이 컨트랙트가 수행할 작업과 수행하지 않을 작업을 검토할 수 있도록 합니다.
| 요구사항 | 결정 사항 |
|---|---|
| 사용자 액션 | 참여자가 어떤 호출을, 어떤 조건에서 수행할 수 있나요? |
| 권한 | 어떤 역할이 관리 작업을 수행할 수 있나요? |
| 베스팅 | 코드가 나타내야 하는 할당 규칙 및 해제 조건은 무엇인가요? |
| 스테이킹 | 제품에 필요한 참여 및 종료 동작은 무엇인가요? |
| 의존성 | 범위 내에 포함된 토큰, dApp 또는 기타 컨트랙트 상호작용은 무엇인가요? |
제품 흐름, 가능한 경우 기존 컨트랙트 주소 또는 코드, 역할 정의 및 알려진 기술적 제약 사항을 준비하세요. 가정을 요구사항으로 처리하지 말고 미해결 결정 사항을 표시하세요. Spec Review에서 해당 가정을 귀사 팀과 확인하고 구현 및 테스트에 영향을 미치는 결정 사항을 기록합니다.
이 정의 단계는 또한 컨트랙트가 독립형인지 더 큰 시스템의 일부인지 결정하는 단계입니다. 토큰 연결은 토큰 생성 및 배포와의 조정이 필요할 수 있으며, 사용자 대면 흐름은 dApp 개발과의 병행 계획이 필요할 수 있습니다. 경계를 조기에 결정하면 컨트랙트 책임을 인터페이스 동작과 분리하여 각 기여자가 올바른 입력을 준비하는 데 도움이 됩니다.
스마트 컨트랙트 프로젝트를 통해 무엇을 받게 되나요?
승인된 범위에 따라 구현된 컨트랙트와 함께, 동작을 더 쉽게 검사하고 인계할 수 있는 자료를 제공받습니다. 정확한 인도물은 작업 시작 전에 확인되므로, 프로젝트가 무제한 기능 목록으로 정의되지 않습니다.
- 범위 기록: 합의된 컨트랙트 동작, 역할, 의존성 및 제외 사항.
- 구현체: 프로젝트에 포함된 기능에 대한 맞춤형 컨트랙트 코드.
- 테스트 자료: 명세서에서 합의된 동작에 대한 검증 증거.
- 검토 지원: 범위에 포함된 경우 외부 감사를 위한 컨텍스트 및 조정.
- 핸드오프 노트: 귀사 팀을 위한 관련 구현 세부 사항 및 알려진 후속 작업.
베스팅 또는 스테이킹의 경우, 인도물은 단순히 해당 레이블이 붙은 함수가 아닙니다. 각 역할에 사용 가능한 액션과 관련 사용자 흐름의 예상 처리를 포함하여 귀사 제품이 승인한 규칙을 반영해야 합니다. 귀사 팀은 해당 규칙이 최종으로 간주되기 전에 검토해야 합니다.
외부 감사에서 변경 사항이 확인되면 합의된 프로젝트 범위에 따라 코드 업데이트를 평가하고 계획할 수 있습니다. 감사 조정은 독립적인 감사 의견을 발행하는 것과 동일하지 않습니다. 공개 사이트나 애플리케이션도 작업이 필요한 경우, Web3 웹사이트 및 랜딩 개발과 컨트랙트 핸드오프를 조정하여 제품 설명과 구현이 일관성을 유지하도록 하세요.
스마트 컨트랙트 프로젝트는 브리프에서 핸드오프까지 어떻게 진행되나요?
작업은 범위 확인, 구현, 테스트 및 핸드오프를 통해 진행됩니다. 이 순서는 미해결 제품 결정이 코드 내에 숨겨지는 것을 방지하고 귀사 팀이 진행 상황을 검토할 수 있는 명확한 지점을 제공합니다.
- 요구사항 수집: 사용자 흐름, 역할 정의 및 관련 기존 자료를 공유합니다.
- Spec Review: 컨트랙트 동작, 제외 사항, 의존성 및 미결 결정을 확인합니다.
- 구현: 합의된 컨트랙트 로직을 구축하고 변경 사항을 명세서에 대해 가시적으로 유지합니다.
- 테스트 및 검토 준비: 합의된 동작을 확인하고 검토 또는 감사 조정을 위한 자료를 수집합니다.
- 핸드오프: 프로젝트 결과물을 제공하고 승인된 범위를 벗어나는 남은 작업을 식별합니다.
일정은 범위에 따라 달라집니다. 규칙이 확정되고 의존성이 제한적인 프로젝트는 제품 결정이나 여러 구성 요소 간 조정이 필요한 프로젝트보다 더 직접적으로 진행될 수 있습니다. 의사 결정권자 한 명을 지정하고, 통합된 피드백을 반환하며, 구현 전에 의존성을 알림으로써 모멘텀을 유지하는 데 도움을 줄 수 있습니다.
전달 중에는 Run Log가 진행 상황, 결정 사항 및 귀사의 입력이 필요한 항목을 기록합니다. 핸드오프 시 Readout은 완료된 작업과 미해결 조치 사항을 요약합니다. 프로젝트에 더 큰 애플리케이션 빌드도 포함되는 경우, Web3 개발을 통해 책임을 조정하여 컨트랙트 작업과 제품 작업에 명확한 담당자가 있도록 하세요.
어떤 스마트 컨트랙트 위험에 명확한 경계가 필요한가요?
프로젝트는 귀사 팀이 검토할 수 있는 코드 및 조정 작업과 독립 당사자 또는 네트워크에 의해 결정되는 사항을 구분해야 합니다. 배포 계획을 승인하기 전에 이 구분을 명확히 하세요.
- 의도된 컨트랙트 동작 및 관리 권한을 문서화하여 확인하세요.
- 기능 레이블에 의존하지 말고 합의된 흐름에 대해 테스트 증거를 검토하세요.
- 외부 검토, 배포 결정 및 핸드오프 후 유지보수를 담당하는 주체를 식별하세요.
- 승인된 컨트랙트 동작에 대한 모든 변경 사항을 범위 결정으로 가시화하세요.
AEOTech는 프로젝트 범위에서 합의된 개발 작업 및 작업 배치에 전념할 수 있지만, 독립적인 감사자가 특정 구현을 승인하거나 네트워크가 선택한 시간에 트랜잭션을 포함시킬 것이라고 약속할 수 없습니다. 감사자 소견 및 트랜잭션 포함은 개발 팀의 통제 범위를 벗어납니다.
실용적인 다음 단계는 사용자 흐름, 컨트랙트 또는 토큰 자료, 역할 정의 및 미해결 질문을 Spec Review를 위해 보내는 것입니다. 이를 통해 프로젝트 경계를 식별하고, 귀사 팀이 내려야 할 결정을 명확히 하며, 작업에 대한 정의된 범위를 반환할 것입니다.
가격
| 서비스 | 가격 | 견적 |
|---|---|---|
| 스마트 컨트랙트 | $1,650부터 / 프로젝트 |
USD 기준 시작 가격입니다. 맞춤 번들 및 볼륨 할인은 요청 시 제공됩니다. USDT, USDC, BTC, ETH, SOL, TON 또는 프로젝트 토큰으로 결제 가능합니다.
이용 방법
- 제품 입력 사항 보내기사용자 흐름, 역할 정의, 관련 기존 코드 또는 컨트랙트 세부 정보, 그리고 컨트랙트가 지원해야 하는 결과를 공유하세요.
- 명세서 확인구현이 시작되기 전에 합의된 동작, 의존성, 제외 사항 및 미결 결정을 검토하세요.
- 구축 및 확인승인된 컨트랙트 범위를 구현하고 지정된 동작에 대한 테스트 증거를 준비합니다.
- 검토 및 인계프로젝트 자료와 완료된 작업, 검토 조정 및 남은 조치 사항에 대한 간결한 기록을 받으세요.
자주 묻는 질문
기존 토큰을 기반으로 컨트랙트를 구축할 수 있나요?
네. 토큰의 관련 코드나 컨트랙트 세부 정보, 제품에 필요한 액션, 그리고 알려진 의존성을 공유해 주세요. 범위 설정 중에 해당 입력 사항을 검토하고 토큰 상호작용이 이 프로젝트에 속하는지 아니면 별도 작업 스트림으로 처리해야 하는지 확인합니다.
서로 다른 수혜자 그룹을 위한 베스팅 규칙을 만들 수 있나요?
네, 수혜자 그룹과 해당 규칙이 프로젝트에 대해 정의되어 있다면 가능합니다. 할당 로직, 해제 조건, 역할 권한 및 그룹 간 차이점을 제공해 주세요. 짧은 기능 설명에서 제품 정책을 추론하는 대신, 구현 전에 동작을 문서화하여 검토합니다.
스테이킹 개발에 인터페이스가 포함되나요?
컨트랙트 범위는 스테이킹에 대해 합의된 온체인 동작을 다룹니다. 인터페이스는 프로젝트 범위에 명시적으로 포함되지 않는 한 별도의 제품 구성 요소입니다. 둘 다 필요하다면 사용자 흐름을 공유하여 컨트랙트와 dApp의 책임을 함께 정의할 수 있습니다.
스마트 컨트랙트 감사를 직접 수행하나요?
해당 서비스는 범위에 합의된 경우 감사 조정을 포함합니다. 이는 독립적인 감사 의견을 대표하지 않습니다. 구현 컨텍스트를 준비하고, 검토 입력을 구성하며, 요청된 코드 변경 사항을 평가할 수 있습니다. 감사 자체는 외부 검토자가 수행해야 합니다.
범위를 요청하기 전에 무엇을 보내야 하나요?
제품에 대한 간략한 설명, 사용자 흐름, 역할 정의, 관련된 경우 베스팅 또는 스테이킹 규칙, 기존 컨트랙트 자료 및 알려진 의존성을 보내주세요. 미해결 질문은 열린 항목으로 포함하세요. 이를 통해 확인된 요구사항과 귀사 팀의 승인이 필요한 결정을 분리할 수 있는 충분한 컨텍스트를 확보할 수 있습니다.
스마트 컨트랙트 개발은 얼마나 걸리나요?
일정은 컨트랙트 동작, 의존성 및 검토 책임이 파악된 후에 설정됩니다. 확정된 범위는 결정 지연을 줄이고 구현 및 테스트를 통해 작업을 진행할 수 있게 합니다. 미해결 제품 규칙이나 외부 검토 조정은 단계를 추가할 수 있습니다. 프로젝트 범위와 함께 예상 일정을 확인합니다.
감사가 컨트랙트를 승인할 것이라고 보장할 수 있나요?
아니요. 독립적인 감사자는 자체 소견과 결론을 결정하므로, 승인은 개발 팀이 약속할 수 있는 사항이 아닙니다. 합의된 구현 작업을 제공하고, 명확한 검토 자료를 준비하며, 감사에서 변경 사항이 확인되면 수정 작업에 대해 논의할 수 있습니다.
프로젝트를 알려주세요
네 가지 질문에 답하면 담당자가 1시간 내로 계획, 일정, 가격대를 보내드립니다. 모든 정보는 비밀로 유지됩니다.
양식 로딩 중…