1 Fixing Kickstarter's Issues
- 캠페인의 외관상 의도는 좋지만 악의적인 의도를 가진 캠페인이라면 ?
- 기부금을 받아 실제 지출하는 것은 캠페인 작성자에게 달려 있음
- 실제로는 다수의 펀딩이 실패하고 펀딩 이후에 제품을 제공받지 못하기도 함
- 이더리움 계약에 자산을 보냄
- Manager는 실제 Vendor에게 금액이 지불되도록 함
- 지불 계약은 특정 돈을 인출하여 특정 사람(외부 공급 업체, Vendor)에게 보내는 계약을 수행
- 여러 기여자들이 인출에 동의하지 않는 경우에 대한 문제를 가질 수 있음
- 단점을 가지고 있지만 이상에 맡기는 것 보다 현실적인 대안을 제시함
2 Campaign Contract Design
- manager: 캠페인을 관리하는 사람의 주소
- minimumContribution: 프로젝트에 기부할 수 있는 다양한 계층(금액)의 최소
- approvers: 승인자, 돈을 기부한 모든 사람의 주소 목록
- requests: 요청 배열, 관리자가 요청한 목록
- Campaign: 생성자 함수, 게약의 최소 기여도와 소유자 설정
- finalizeRequest: 최종 결정에 대한 함수, 금액이 지불되지 않았는데 승인되는 경우를 방지하기 위함
3 Campaign Constructor ~ A Quick Test
4 The Request Struct
- description: 서명, 관리자는 요청에 의해 인출, 지급되는 돈을 정당화해야 함
- value: 관리자가 원하는 금액
- recipient: 공급업체의 주소, 돈을 받을 사람
- complete: 요청이 이미 구매되어 있을 경우 다시 구매되는 것을 방지하기 위한 bool값
5 More on Function Modifiers ~ Storage and Memory
- 요청에 대한 구조체를 정의
- 수정자, Instance Creation Syntax
- createRequest // Storage와 Memory를 혼용한 오류 발생
- Strorage는 영구적인 데이터를 저장하는데 사용
- Memory는 임시적인 데이터 보관소 RAM -> minimum
6 More on Storage vs Memory
- Memory에 있는 int[]에 접근하고자 하나 Starage에 있는 int[]에 접근할 때 오류 발생
- 변수 선언부에 memory임을 명시해줘야 함
7 Voting System Requirements
- 단일 기여자는 한 번의 투표만을 할 수 있도록 해야함 -> 한 사람당 하나의 의사표현
