VIDT DAO security record

In the contract `Controllable` the role `controllers` has authority over the functions shown in the diagram below. Any compromise to the `controllers` account may allow the hacker to take advantage of this authority and - add a controller to controllers through `addController()` - remove a controller from controllers through `removeController()`  In the contract `VIDT` the role `controllers` has authority over the functions shown in the diagram below. Any compromise to the `controllers` account may allow the hacker to take advantage of this authority and - set validation price through `setPrice()` - set validation fee through `setFee()` - set validation wallet through `setWallet()` - set the address of `_nftContract` and `_nftdContract` through `setContracts()` - list files through `listFiles()`  In the contract `VIDT` the role `_validationWallet` account can withdraw all arbitrary tokens and BNBs of the contract through `transferToken()` and `withdraw()`.

`1e27` tokens are sent to `msg.sender` when deploying the contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

DelegateCall, as the name implies, is a calling mechanism of how caller contract calls target contract function but when target contract executed its logic, the context is not on the user who executes caller contract but on caller contract. So all developers should be aware of the risk that the `target` address may do harm to the current contract, such as calling the `selfdestruct()` or modifying the storage. In addition, it may also cause function clashing. Refer to https://forum.openzeppelin.com/t/beware-of-the-proxy-learn-how-to-exploit-function-clashing/1070.

1. Creating an NFT in the function `validateNFT()` is based on whether it is divisible or not, but the function `validateFile()` is not. 2. The function `validateFile()` supports token or BNB payments, there is no strict restriction to only one kind of payment, so that the user may pay both at the same time. The functions `memoryValidateFile`,`validateNFT()` and `covertValidateFile()` have the same issue. If both `cStore` and `NFT` are `false`, the logic is similar to the function `covertValidateFile()`. 3. The functions `simpleValidateFile()` and `covertValidateFile()` do not support `allowances` and have inconsistent function names and logic. What is the purpose of these two functions?

There is a hardcode address in this codebase.