update roadmap

[b00f]

Update roadmap and fix a typo

[kehiy]

@b00f I have some comments on the roadmap and also this issue on core: pactus-project/pactus#1341

So, I decided to explain it here, I hope I explain it clearly. When we are trying to add different stuff before supporting on-chain arbitrary logic (contracts) that means we are forced to apply them on core logic and source code. for example:

1. A batch tx support at the moment requires changing our execution and sandbox module which affects our APIs to the outside world as well and applying changes on our transfer tx format as well, also users are limited to using this purely and they can't apply conditions on it and make it dynamic and their only way will be using off-chain code. but if we first support contracts, users can simply write and deploy a contract that splits a payment. they can apply conditions and logic there, and they can show their conditions to everybody with proofs since it's transparent and customized, also we didn't add any complexity to our core layer.

2. Creating a password manager project for now only has 2 possible ways: have some centralized parts, or change the core. we know both of them have a lot of cons. but with contracts, anybody can implement a password manager and also we can give this project to teams and the community to simply do it without struggling with core.

3. To change chain params right now we have to change JSONs in our code and after any change we need to make a software release to be applied!!! which is not logical since a p2p blockchain network can benefit from its aliveness. with smart contracts, we can make a contract which is called chain config, and deploy it in the first block that going to be created after contract support. after that, the validators will read their parameters from this contract dynamically. when someone wants to change it they can make a DAO proposal (a DAO contract can be deployed the same as config one) and if it gets enough votes it will be applied and validators will automatically update with it. no need to release or update. it can have constant and dynamic parameters and ...

4. To support gas-lees transactions, at the moment we are thinking of a solid model of transfer, bond, unbond, and withdraw model. but I believe Fees are paid for executions and storage, when we haven't completed and finalized our execution mode at all, we can decide on fees and it has the potential of changing again! but if we finish the reason that we have fees, we can decide on fees better.

So, that's my reason to keep the contracts a higher priority since it can do most of these things more cleanly and simply. that's like making a domain-specific machine for any possible situation or just making a general-purpose CPU and it's done.

[b00f]

We discussed about it in last meeting!