컨트랙트 설계 시 추가로 고민해야할 부분

1. 수 많은 제안 중 어떤 기준으로 제안을 선정하여 투표를 시작할 것인가.
: 모든 제안을 투표를 하기에는 무리가 있습니다. 국민청원에서도 쉽게 볼 수 있듯이 거버넌스에서 어떻게 할 수 없는 안건이 올라올 수도 있고, 거버넌스에서 안건으로 올리기에는 사안이 너무나 미약한 것일 수도 있습니다. 또한 모든 제안을 투표로 한다면 투표 건 수가 걷잡을 수 없이 많아져 모더레이터들의 참여율과 관심도가 줄어들 가능성도 있습니다. 그리고 불필요한 투표가 많아지면 블록체인 상의 스토리지를 많이 차지하게 되어 비용도 높아지겠지요.

2. 투표에 통과한 제안을 어떤 로직으로 실행시킬 것인가.
: 투표가 끝난 뒤 정족수 이상을 얻은 제안을 운영부서(ex 초기에는 dao를 개발한 팀이 되겠지요)에서 별도로 실행하는 방법이 있을 겁니다. 하지만 이 방법이 좋아보이지는 않습니다. 코드에 의해 자동으로 실행되는 것이 아니라, 결국 누군가의 손에 의해 실행되는 것이라서 잘못된 메서드를 실행하거나 매개변수를 잘못 입력하는 경우 등이 있을 수 있습니다. 또한 악의적인 목적을 가진 누군가가 DAO를 공격하고자 할 때 공격 포인트가 실행하는 server 한 군데로 압축이 되어 블록체인의 최대 강점인 보안성도 살릴 수가 없겠지요.
가장 좋은 로직은 투표가 끝나고, execute 메서드를 실행하면 자동으로 제안에 있던 함수가 실행되도록 하는 것인데, 코드로 옮기기가 쉬워보이지는 않습니다. 충분한 고민이 있어야 할 것 같아요.

3. 다양한 제안들이 올라올텐데, 단순하게 몇 가지로 추상화시키는 방법이 있는가.
: 예를 들어 새로운 사업에 투자를 한다든가, 법무 계약을 위임한다든가, 자산을 새로 구입한다든가 하는 것들은 공통적으로 돈을 지급하는 형태이죠. 이런 경우 transfer 함수 하나면 될겁니다. 돈을 주면 운영부서에서 알아서 하도록 말이죠. 또한 플랫폼 이용 수수료라든가 staking한 토큰에 따라 받게 되는 배당금이라든가 이런 것들은 컨트랙트 내부의 변수를 변경해주는 set 함수를 만들어 두고 나중에 투표 결과에 따라 실행만 하면 될겁니다. 그 밖에도 다양한 회사의 활동들이 있을 것인데, 그런 것들의 공통점을 추상화 시켜서 최대한 단순하게 만들 방법을 고민해야 할 것 같아요.

No files or tests are identified. Start by reviewing the contract design around proposal selection, voting completion, and the execute method; compare the proposed transfer and set operations with the desired abstraction for different proposal types. Done means the governance and execution design questions in all three sections have an agreed implementation scope.

Written by the indexing model from the issue text.