Security Improvements for proposal contracts

[weiqiushi]

Consider an attack on our centralized backend, where both the backend code and the database can be modified, it is possible to reach the following attack:

1. someone creates a normal project proposal with a proposal id of 100
2. through the code, he created a malicious Token release proposal, the proposal ID is 101
3. by modifying the backend database, the ID of the project proposal is changed to 101 in the backend.
4. when other people vote in the front-end, they see the description of the project proposal, but when they vote, they vote for the malicious proposal 101.
5. when 101 is passed, it can operate the release token interface to release the token to itself. In order to stop this attack, we need to add validation to the chain to prevent the backend from voting for the wrong proposal. The solution I'm considering is as follows: Use the params[] validation function of the proposal.

• [x] when creating a proposal, fill up the params of the proposal with parameters + type, the type is added to avoid the situation that some simple proposals have a small number of parameters and conflict with other proposals.

  Example: add member: [member address, "addMember"]. Remove member: [member address, "removeMember"]. Create project: [budget, issueId, startDate, endDate, "createProject"].

• [x] these parameters are also stored in the backend database
• [x] modify the voting interface in the chain to support(uint proposalId, bytes32[] memory params) The params here need to be passed the same as when creating the params.
• [ ] when the front-end creates a voting transaction, read out the corresponding parameter list of the proposal from the back-end.
• [ ] in the proposal display, the front-end directly read the proposal parameters, and then according to the type, using a template to spell out a human readable description
• [ ] the front-end can calculate its own params hash through the proposal parameters, and then compare it with the hash on the chain to determine whether the proposal is valid.
• [ ] in order to prevent the front-end code is tampered with, resulting in the creation of transactions using the wrong parameter list, you can consider the front-end encapsulation in electron, and distribute it

If above scheme is applied, then the previous attack, will become: If the attacker only modifies the proposal ID, then when the front-end is displayed, modification 6 will prevent this proposal from being displayed If the attacker modifies both the proposal ID and the proposal parameters, then when the front-end is displayed, modification 5 will be displayed as a Token to release the proposal In both cases, the vote will not succeed and the attack fails In the case where the back-end code may have been modified, there is no need to do any other validation logic in the backend, because there is a possibility of being bypassed in both cases

[weiqiushi]

All current proposal`s params has been defined, porposals.md

[weiqiushi]

@alexsunxl