|
|
@@ -129,3 +129,113 @@ release to show up on the Download page.
|
|
|
<td>release</td>
|
|
|
</tr>
|
|
|
</table>
|
|
|
+
|
|
|
+## Mainnet Roadmap
|
|
|
+
|
|
|
+High-level explanations and tasks on the mainnet roadmap, in no
|
|
|
+particular order. Some may depend on others, use intuition.
|
|
|
+
|
|
|
+### DAO Smart Contract
|
|
|
+
|
|
|
+The DAO needs to have a parameter that defines the length of a
|
|
|
+proposal and the time when it is allowed to vote. Could be a start
|
|
|
+and end time or just end time. After end time has passed, new votes
|
|
|
+should be rejected, and only `DAO::Exec` would be allowed.
|
|
|
+
|
|
|
+The DAO also has to implement ElGamal-ish note encryption in order to
|
|
|
+be able to be verified inside ZK. `darkfi-sdk` already provides an
|
|
|
+interface to this, although not providing an interface to the zkVM,
|
|
|
+just external. (See `ElGamalEncryptedNote` in `darkfi-sdk`). The
|
|
|
+cryptography also has to be verified for correctness, as this was
|
|
|
+just a proof of concept.
|
|
|
+
|
|
|
+### Smart Contract Client API
|
|
|
+
|
|
|
+The native contracts should have a unified and "standard" API so
|
|
|
+they're all the same. Perhaps it is also possible to define some
|
|
|
+way for contracts to expose an ABI so it becomes simpler and easier
|
|
|
+for clients to get the knowledge they need to build transactions and
|
|
|
+chain contract calls with each other.
|
|
|
+
|
|
|
+### Passive APR/APY
|
|
|
+
|
|
|
+Consensus participants should be incentivised to stake by getting
|
|
|
+rewards for participation. We need to find something useful for them
|
|
|
+to do in order to receive these rewards, and also we have to find a
|
|
|
+way to ensure liveness throughout the entire epoch. The solution to
|
|
|
+this should not be something that congests the consensus/transaction
|
|
|
+bandwidth or increases the blockchain size a lot.
|
|
|
+
|
|
|
+### Non-native Smart Contract Deployment
|
|
|
+
|
|
|
+There is a basic smart contract called `deployooor` that is used as
|
|
|
+a mechanism to deploy arbitrary smart contracts on the network. We
|
|
|
+need to evaluate the best way to support this. The WASM needs to be
|
|
|
+verified for correctness (e.g. look through the binary and find if
|
|
|
+all symbols are in place) so that at least here we disallow people
|
|
|
+from writing arbitrary data to the chain.
|
|
|
+
|
|
|
+### Transaction Fees
|
|
|
+
|
|
|
+TBD
|
|
|
+
|
|
|
+### `drk`
|
|
|
+
|
|
|
+UX!
|
|
|
+
|
|
|
+We need to handle confirmed and unconfirmed transactions, make things
|
|
|
+prettier and better to use. When broadcasting transactions, if they
|
|
|
+pass locally, the wallet should be updated to represent the state
|
|
|
+change but things should stay unconfirmed. The DAO SQL schema gives a
|
|
|
+nice way to do this, where there's a `tx_hash`, `slot_id`, etc. which
|
|
|
+can be used to evaluate whether the transaction/coins/whatever was
|
|
|
+finalized.
|
|
|
+
|
|
|
+We also discussed about having clients handle their own wallets,
|
|
|
+and not providing a sink through `darkfid` where there's a single API
|
|
|
+for interfacing with the wallet, and having to be closely integrated
|
|
|
+over JSON-RPC <-> SQLite glue. `darkfid` will only ever have to manage
|
|
|
+secrets for the consensus coins that are being staked and won't have
|
|
|
+to deal with the entire wallet itself.
|
|
|
+
|
|
|
+### `darkirc`
|
|
|
+
|
|
|
+Write documentation about usage. We need proper tutorials about
|
|
|
+running on mobile. Both weechat-android setups, and local ones.
|
|
|
+
|
|
|
+A simple Android app can be made drawing inspiration from Orbot
|
|
|
+where there is a big On/Off button that can start/stop the node on
|
|
|
+the phone and then the user can use any IRC client they prefer.
|
|
|
+
|
|
|
+### `tau`
|
|
|
+
|
|
|
+TBD
|
|
|
+
|
|
|
+### P2P
|
|
|
+
|
|
|
+The P2P library needs a complete test suite in order to more easily
|
|
|
+be able to make changes to it without introducing regressions. This
|
|
|
+includes bad network simulations, latency, etc. The P2P stack also
|
|
|
+needs to be able to heal itself without restarting the application,
|
|
|
+much in the way like when you unplug an ethernet cable and then
|
|
|
+plug it back in. Currently when this happens, all the P2P hosts
|
|
|
+might be dropped from the known hosts db as they're considered
|
|
|
+offline/unreachable, so we might want to implement some kind of
|
|
|
+"quarantine" zone instead of deleting the peers whenever we are unable
|
|
|
+to connect to them.
|
|
|
+
|
|
|
+In the TLS layer of P2P communication, the client-server certificate
|
|
|
+logic needs to be reviewed for security and we should define a protocol
|
|
|
+for this.
|
|
|
+
|
|
|
+### zkVM
|
|
|
+
|
|
|
+The zkVM has to implement dynamic self-optimising circuits. The first
|
|
|
+part and the scaffolding for this is already in place, now we need
|
|
|
+to come up with an optimisation algorithm that is able to optimally
|
|
|
+configure the columns used in the circuit based on what the circuit
|
|
|
+is doing.
|
|
|
+
|
|
|
+All the zkVM opcodes need to be benchmarked for their performance
|
|
|
+and we need to see how many columns and rows they use so we're able
|
|
|
+to properly price them for verification fees.
|
parazyd