고려사항

실제 Lottery 서비스를 운영하는 입장에서 생각했다.

1. draw()는 서비스 제공자가 직접 호출한다.

   • 예측 불가능한 난수를 기반으로 동작한다는 전제 하에, 유저들이 draw() 함수를 직접 호출할 유익은 없다.
   • 예측 가능한 난수를 사용하는 경우, 이를 악용하려는 사용자로 인해 draw()가 직접 호출될 수 있다.
   • 그러나 이 컨트랙트 이용으로 얻을 수 있는 수익의 기댓값은, 모두가 최선의 선택을 내린다고 가정했을 때, 가스비를 고려하면 100% 미만으로 수렴한다.
   • 추가 인센티브가 없다면, 이 컨트랙트의 사용자는 없을 것이다. 이러한 내용을 고려하여 서비스 제공자가 직접 호출하는 상황이 최선이라 생각했다.

2. draw()를 통해 제공자가 필요한 storage 조작을 모두 끝내면, 유저는 언제든 claim()을 통해 상금을 얻어갈 수 있도록 구상했다.

   • 유저 입장에서는 매 라운드마다 claim()을 호출할 필요가 없기 때문에 가스비가 크게 절감된다.
   • 또한 언제든 호출이 가능하기 때문에 편의성의 측면에서도 훌륭하다.

3. 본 컨트랙트의 구조에서는 draw와 sell, 2개의 phase만 구분하면 된다고 생각한다.

   • 테스트 코드에서는 claim()을 sell phase에 호출하지 못하도록 강제하고 있기 때문에, 불필요한 코드 중복이 발생한다.

컨트랙트 가독성

1. 적절한 annotation
2. interface 분리
3. struct, enum 사용
4. modifier 사용
5. internal functions 분리

gas-report